I have the need to have 2 html forms on one page. One for login details, and one for feedback. Both forms cannot have runat="server" attrib.
Any suggestions?
Handle one of the forms as a regular HTML form -- don't use runat="server". Extract the values from any post from the Request.Form collection manually (since there won't be any server-side variables corresponding to the form).
Alternatively, put all the elements in the same form, but use different controls to submit. Each set of controls (and their submit button) should be in a different validation group to avoid having validation errors due to elements you don't care about. Handle the form processing in the callback for the submit button.
Also, I would recommend an eventual move to ASP.NET MVC. MVC is a much better architecture from the perspective of the web. It more closely aligns with the stateless web model and does not have the limitations imposed in ASP.NET to help it mimic WinForms development.
When using web forms, you should only ever have one form on the page. Probably crap, but such is a web forms world...
wrap one form around the whole page. Then when a button is clicked (or whatever event you are using) you should be able access the values of all the controls on the page.
Yes as you said, in ASP.NET you can't have more then one form element. but, you can handle more then one action in the same form. Do not use form's action attribute, use asp.net server controls like <asp:Button>, and write your logic into the event of the controls that post back.
ASP.NET page framework architecture allows single form with runat="server" attribute. You need not to worry about this thing. Place the controls on to the webform for two different purposes and handle the click events of two asp.net server control <asp:Button> separately.
You just have to split them up logically inside the one form. If you use validator and don't want the two "forms" to require the other values filled in, you have a property on the .NET controls called ValidationGroup, that just needs to be the same for all in one "form".
You won't be able to make two forms with runat="server" in one page.
Here is a nice solution
Can I have two separate forms runat="Server" in one page
though not a straight forward approach, you CAN have multiple server side forms on the same page , but it has its own limitations. Cost $50
Related
So far, all the web pages I met contain at most one <form> tag. Why not multiple ones? I can not think of reasons why multiple forms can't coexist within the same web page.
Also, to be specific to ASP.NET - why are all the server controls are placed within the <form> tag? Why not place them somewhere else?
Plus,
I noticed that in an .aspx file, the <form> tag has the runat=server attribute, while a normal server control such as Button also has one. So it seems the <form> is also a server control. But strangely enough, I cannot find it in the Visual Studio Toolbox.
There can be multiple forms, with hacks.
It is indeed a shortcoming of WebForms. In ASP.NET MVC you can implement as many forms as you want (and it is valid & correct behavior of web pages).
The reason all server controls are placed inside <form> tag is to allow the WebForms engine to recognize them, load their values & save their values from/to the ViewState. Almost all infrastructure of control management in WebForms is based on the idea that a tag contains everything you access from the code-behind.
As pointed out, this is one of the shortcomings of WebForms. I do want to point out, additionally, that with cross-page posting and validation groups, you can typically reach your desired behavior (for most "multi-form" solutions).
Regarding the additional question: the <form runat="server"> is parsed as HtmlForm class behind the scenes, which inherits from HtmlControl like any other HTML element with runat="server".
Unlike any other HtmlControl though, there can exist only one instance per page and it does not appear in the toolbox as it's added automatically to every new Form you create, so it's quite pointless.
Yes, it can be done - by creating a custom HtmlForm object and toggling the forms as needed. I've just answered a similar question here (with code):
Paypal Form Ruins My ASP.NET webforms layout -> How to Solve?
many non server forms - you can , but only one runAt Server form
i also found this :
A server-side form tag is the tag which has a runat="server" attribute. If this attribute
is missing, then it's a typical HTML form tag. The conclusion is that you are allowed to use
multiple form tags on a page, as long as only one has the runat="server" attribute. The
disadvantage of the form that doesn't have this attribute, is that view state won't work
(meaning form values will disappear when using the back/forward browser buttons). It's a
small price to pay if you really need multiple forms on a page.
Take master page & set design.
Take one form in master page.
Second form take in contain place holder.
In contain place holder in only for write form tag (not use)
Add aspx page & design second form but not write form tag only for control put
Take button click event fire code write
This is proper way of two form
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 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.
ASP.NET has a number of nice features regarding making data input pages:
Adding input controls is easy (<asp:...).
The system automatically generates member variable for the controls.
Post-backs automatically populate the members variable with the returned values.
and some not so nice bits
post-backs seem to be tied to JavaScript for even the simplest of cases. For instance, with statically defined pages, using only basic controls, that are known at compile time.
My questions:
Is is possible to get the first list without the second?
What features does that JavaScript give the user?
What does that JavaScript actually do?
What is the technical reasons that it's used even in trivial cases?
As it happens my assumption were in error: See here
It really depends on the types of controls you are trying to use here -- the only ones that implement javascript are those that can't natively cause a postback (ie, an input/submit button are the only two that can). If you are using a LinkButton, ImageButton, or anything that you set "AutoPostBack = true" on will turn javascript on in order to cause a postback.
Other controls can also potentially use javascript if they are more advanced such as the Calendar. The technical reason for using javascript here is to provide automated postback when the controls require more advanced server interaction -- think about it, a link is meant to only ever be a link and if we're trying to make it operate as a button we have to force it to do just that through javascript interaction.
So that being said, yes you can definitely use ASP.NET without it having javascript you just have to avoid the controls that implement it by including functionality you couldn't possibly have without it. You can just as easily add HTML controls and add the runat="server" attribute and gain member variables to the control from code-behind.
Here's what came to my mind:
What features does that JavaScript give the user?
Client side validation.
What does that JavaScript actually do?
For exmaple, it ensures that the correct (server-side) event handlers are called, by setting the __EVENTTARGET hidden field.
Is is possible to get the first list without the second?
You can use normal HTML controls instead of the ASP.NET controls. Then on the server-side, you can read the control's values from the Form collection.
I assume you mean the javascript associated with an <asp:Button /> control, right?
In addition to the reasons mentioned by Fooberichu, the javascript can also help with ASP.NETs client side validation framework.
But I think it's primary use is to alert the framework what events it should fire on the postback in the page behind.
So if you had two buttons on the form, SaveButton and DeleteButton, the javascript helps the framework know whether it should execute the SaveButton_Click event or DeleteButton_Click event.
Hope this helps.
I have a requirement wherein I have a bunch of about 10 aspx pages.The user shall be able to go from one screen to another using navigation.All the range , custom,regex validators need to file so that data enetered is correct.Required fields need not be entered at this stage and the user can skip required fields. On the last page, I need to find out all the fields which are required and if incomplete want to show the user, these fields are required, sort of summary with link to the page where the control was left blank.
Does any one have any good ideas to achive validation on pages which the user has left and can do validation at the very end before the data is submitted. Any pointers would be greatly appreciated.
Validators form part of the page on which they lie. You cannot use the built-in validator controls to validate input fields on previous pages in the sequence. If you must do it this way, then you should implement your own validation framework which validates data on each page, but provides feedback on the summary page.
You should look into the usability issues faced if you only give feedback to the user at the end of the sequence of pages. He/she will be required to go back a few pages and retry input there. I don't think that is a good option at all.
A much better option would be to use the ASP.NET Wizard control (which loads sequential UI in separate panels, but on the same page). That would enable you to use Validators in conjunction with your setup. This article by Steve C. Orr provides a good introduction to using Validators with the Wizard control.
Alternatively, you can use the AJAX Tab control as others have suggested.
You can achieve this by using i.e. a TabControl (ships with the Ajax Control Toolkit).
Same thing I am applying in Asp.net MVC but I suggest you to use Tab control rather to use Bunch of pages as sshow posted.