views:

292

answers:

2

Hi this may seem like a weird question, but here's my situation:

I have a form where the user can click and add rows which contain certain input fields. This is strictly done on client side using JQuery. I can access the input values on postback on asp.net side using Request.Form and the name of the fields, which is fine. The problem is when the page posts back, the fields obviously disappear. So I have no way of doing error validation or other stuff. What are my possible solutions here? Should I dynamically generate the corresponding fields on server side when postback happens and put the already read in values from the client side generated fields so that it's transparent to users? Is that a round about way of doing things? Is there a better way?

I was thinking of adding an ajax method on the server side which would return back validation info and I could use that to signal errors or what not on client side without ever posting back, but the button that causes the post back is the "next" button, and I need it to go to the next page if there are no errors.

I'm looking for any more insights someone might have and pros and cons of the approaches.

Thanks

+1  A: 

If you want to add input fields dynamically, you will have to maintain a server-side hash of the newly added fields and re-instantiate them in Page_Init in order for them to persist between postbacks.

I think your AJAX idea is good:

  1. call a server-side method via jQuery (this can be a static method on your .aspx page.) The server-side method adds a string value to a Session-stored List<String>.
  2. Have the method return the string value, which is the ID of the element to add to the page.
  3. Add the elements to your page with jQuery.
  4. Use the session variable to reinstantiate your dynamically-added fields on postback.

This method gets you the speed of adding the fields on the client side, and keeps your dynamic fields from disappearing on postback.

Dave Swersky
this is good, except, how do I have the method generate IDs in step 2 which will reflect the ASP.NET generated IDs on reinstantiation in step 4? The reason being, that I'm also allowing users to remove certain rows on button click, and I wanna keep all the ids consistent whether generated client side or server side after postback.
You don't have to worry about the "ASP.NET generated IDs"... as long as you set the same ID on the control when you reinstantiate. ASP.NET will handle the rest. You'll have to come up with ID generation logic yourself.
Dave Swersky
+1  A: 

1) Quick and dirty, you could use an UpdatePanel, but that would increase the size of the traffic some. It would allow you to include validation controls by posting back the whole markup for the table.

2) You could use some kind of CustomValidator or custom validation method and just use the Request.Form values. As long as you have some way to identify the fields you should be able to work that out, but you'll have to recreate the scene if the postback fails since you'll lose those parts.

3) You could do the whole "postback" via a WebMethod call and handle everything manually. This is probably the cleanest way to do it since you are mixing and matching the traditional WebForms stuff with a more clientside model anyway.

Jared