I have a standalone webform (no masterpage) that opens in a div from another page. The standalone page uses jquery to move a user through a non-linear questionnaire. At the end of the questionnaire there is a result displayed with a "complete" button. When the user hits the complete button the result is sent back to the parent/host page of the div.
I have a new requirement where i need to actually pass the question and answer id's to code-behind or web service where i can insert the question and answer id's to my DB.
None of what i need to do requires object serialization. I want to do this as simply as possible.. none of the controls in the questionnaire are server controls.. just regular select boxes or radio button groups. I suppose i could do an ajax postback using an update panel or something but not sure if making the controls runat=server will screw up all the jquery/js i have working in the questionnaire.
Any help is appreciated thanks!
I would tackle this by using jQuery to post the data to a web service, which is fairly trivial. There's are a couple of code examples for doing this with asp.net here:
jQuery: Ajax call to asp.net webservice fails, server return 500 error
and
Calling a webservice through jquery cross domain
To answer your other question, putting runat="server" will not have an affect of jQuery's ability to parse the elements in the DOM.
Related
I believe this is a fundamental question regarding asp.net's way of manipulating database items. Basically the server side way of manipulating database items (using ListView or similar) is outdated due to the post back model is outdated compared to AJAX. Let's say you have forward and backward buttons on the gallery to update images from the database. You need to postback in order to update page. Clearly this could use an ajaxfied approach. I have been thinking about this long and hard and have observed most websites that uses ListView or GridView or whatever do not ajaxfy the process, probably due to the difficulty of this problem. For those that ajaxfy the page, they use the UpdatePanel, which is only "pseudo-ajax".
I would like to know do other programmers have a FULLY ajaxfied way of updating a page of a photo gallery, retrieved from database by ListView? As I said I have been thinking about this long and hard and I think there might be two approaches: First, use ListView to first populate photo gallery. On pressing forward or backword button, use jQuery's ajax method to connect to an .ashx page and use .ashx page to retrieve data items and then use jQuery to update the photo gallery at the client side.
The second way I forsee would be abandoning the ListView altogether and use a for loop in .ashx to populate gallery from the beginning. This approach unifies the initial data retrieval method and the "postback" data retrieval method, which could mean less code needed, since you do not need the aspx page at all.
My question is, what is the realistic way to fully ajaxfy the page mentioned above?
I still use code behind in my asp.net website.. but I do use ajax elements on the .aspx page
take a look at ASP.Net Ajax Control Toolkit
All the Ajax elements, with the benefit or still using code behind
So far the best way I have found would be to use jQuery AJAX to update whatever changes, although it can be much more time consuming than posting back to server and update from there
I am currently working with ASP.NET and the person who designed the form has used all Server Controls for things like TextBoxes and Dropdowns etc when really they are not providing postbacks.. Some of the dropdowns and textboxes are values that I need only in jQuery so as far as I can see there are no drawbacks to coverting these controls to standard html controls rather than ASP.NET server controls?
I suppose I will need to continue to have my GetDataGrid button as a server control because I will need it to postback (and receive PageLoad events etc - all asp.net events) to update the GridView? Or would it be possible to use the GridView (ASP.NET server control) from a Webmethod and call it via Jquery?
Of course in my webmethod I would need to the instance of the gridview to add the datasource - but I don't see how this would be possible without being in the ASP.NET events - or maybe I wrong?
The other thing I thought of was changing the GetGridView button to a standard HTML and calling the javascript postback from the client click event?? This way it would do a real postback and I would end up in Page_load.
Taking everything into effect i don't want to the change the GridView asp.net control as it funcions well as an asp.net server control but i am unsure how i would do this.
I remember a document being available that said "how to use asp.net webforms without server controls" but i can't seem to find it. I suppose using webforms like asp.net MVC - but i can't change the project to MVC - its out of my control.
I would love to hear some feedback with regards to how to do this or comments etc.
I find ASP.NET webforms to inject a lot of code smell into pages - I am using .NET 3.5 so a lot of the output is with tables etc...
If you use Request.Form["..."] then you can get the information which was filled in in standard html input fields.
Instead of keep on using the GridView control I suggest you take a look at either jqGrid or the new templating system that Microsoft put into place for jQuery (currently a plugin but expected to be part of core jQuery from version 1.5 on). These can bound to json which can be retrieved from a webmethod or pagemethod call to fill up the template with data.
Also i don't think its possible from asp.net (code behind) to receive values of an html >control without it having runat=server.
Use webmethods.
Set a client event (like 'onchange') on the html control and then in javascript function called when the event is fired you can use PageMethods to send your data to the code behind.
Some thoughts...
The GridView can't be created in a WebMethod and even if there was a way to get that to work, you'd be better off going with a genuine client side grid. As that's not an option, I don't think there is too much point in trying to make any major changes to your existing pages.
ViewState
Changing the textboxes, buttons etc to HTML versions, would gain you a little bit in reduced Viewstate size but add a bit of complexity in how you handle interactions with the page. You can add runat="server" to HTML controls which will give you control over what is rendered and still have access to the control on the server side.
.Net 4 gives you far more control over viewstate but unfortunately in 3.5 its not as easy.
The GridViews
You could wrap the GridViews in UpdatePanels. That's a 'cheap' way to add some interactivity to your pages although you won't be gaining anything in terms of performance.
It's also still possible to manipulate the Gridview using jQuery on the client-side. There a lots of tutorials, blog posts etc explaining how to do this on the Internet.
MVC with Webforms
Its also possible to mix ASP.Net MVC with Webforms in the same website. As it sounds like you are familiar weith MVC, you might want to consider this approach for any new pages. Here's a blog post explaining how to do this.
Update:
Here's a more recent article by Scott Hanselman on how to use MVC with an existing Webforms application.
I have an aspx page with a set of controls.
A small JS script written on top of jQuery allows the user to drag "li" elements from one list to another.
What I would like now is for my C# code to be able to figure out which items the user has placed in which list after the page is posted back to the server.
Does anyone know how I can do this?
Thanks.
Without some specifics, its hard to get into details. But for ASP.NET server-side controls, the trick is properly maintaining viewstate (or just bypassing it). So strategically you've got two fundamental options:
1) Track the changes server-side by using AJAX to push updates to the server.
2) Track the data client-side by updating some element ASP.NET could understand. My personal favorite is to use a hidden form field that I add a user's "moves" to in a format that can be replayed in my web form.
The easiest way to do it would be to add a HiddenField to your page. Whenever the lists change, populate the HiddenField's value accordingly. When a postback occurs, the HiddenField's value will be available on the server side.
What i've done in the past with drag & drop functionality in ASP.NET, is read the DOM elements via jQuery, and do an AJAX postback with the values in those DOM elements as a parameter.
I have a web page devoloped in visual studio 2008.
I have 4 dropdowns and a repeater in the page.based on the selection(search criteria) from the dropdowns the repeater value will change.
and one dropdown selection will bind values to the other dropdown also.
Since the page is causing a lot of postback we decided to implement ajax here.
I am yet to learn ajax.
Can anyone tell what is the best way to do this .which ajax control replace dropdowns?
i have already server side code written on all dropdowns.
Please give me a good solution which i can implement in less time and reuse my code.
One more update: i have a master page used in the project.
I am using update panel of ajax which does not work if i use master page.
(That means all the dropdown controls and repeater i put it in update panel.But still page postback occurs.)
In a normal page(without master page) it works? why is this happening?
Thanks
SNA
You are able to use UpdatePanel and place dropdowns inside it.
Your solution will depend on the AJAX framework you choose, but here are cascading dropdown examples in ASP.NET AJAX and jQuery
If your main reason for using AJAX is to remove the number of postbacks you are getting, then I would recommend against using Microsoft's built in solution, e.g updatepanels.
The learning curve will be higher but learn to use jQuery, maybe with a little help from jTemplate to help you build your drop downs on the page.
Using updatepanels will not reduce your postbacks as behind the scenes asp.net is doing a full page life-cycle, sending all content back to your client but only updating the update panel. jQuery will be far more efficient. (and the reason I use it!!)
Update
If you don't believe me, see... Why Update Panels are dangerous
Update #2
If you don't want to go the whole way of learning Ajax just yet (although I'd recommend it) you could always pre-load your page with all the possible drop down combinations and then swap them using javascript / javascript + jQuery.
Here is one example of how you may do it -- use jQuery for dependent drop down combos
Using this method you are more likely to be able to save the code you've already written to work out the drop down options.
I realize that ASP.NET is only designed to support a single form. What I am confused about is what is the appropriate method for coding multiple "forms" on a .NET page (I have a login form at the top of the page, via the Site.Master and other forms will appear on any given page). Am I supposed to respond differently? It doesn't really make a whole lot of sense. I would appreciate it if someone could clarify. Thanks.
P.S. I am currently developing on .NET 2.0 although I plan to move to .NET 3.5 soon.
Nearly all ASP.NET Web Forms post back to the same page. Unless you are working on some strange outlier (which your question doesn't indicate), you just use one form tag around the entire document, and use event hookups to your controls to handle the various instances.
For example, you can have three buttons that act as Submit buttons, one for each "form" but all inside that same form tag, and each one will call its respective event. This behavior is standard and handled by ASP.NET for you; all you have to do is write the event handlers and wire them up.
I'm not sure what you mean by a logon form. Are you doing some special ajax stuff?
You should be dividing any logical "form" as you call it into its own usercontrol.
http://www.asp101.com/lessons/usercontrols.asp
When dealing with aspx pages, think of the form on the page the same way you think of the body tag.
In that case, I would hand-code the login form at the top to submit to a separate login.aspx page. Leave the rest of the page to the other form's own purpose.
by default you can't, it's how the whole webforms technology works (MVC would probobly fix this in the newest versions).
So really it depends on what you want the "two forms" to do. For example, there's no issue with having login & search on one page, as each button has its own click event and go from there. If you wanted a second aspx page to process one of them, you could collect values and pass them through a response.redirect or some other hacky solution.