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.
Related
I have an odd question that im not sure has been asked/answered, and im not sure if mvc can do this but:
I have a really massive page/controller which i have been able to code well enough. The user can edit information on this page and wont get it saved to the database unless they specifically say, save. However, there is a list at the bottom of this page that you can add/edit and delete elements. Adding and editing takes you to a different page, and before the page change happens, i want to save the form data to session memory, but i dont know how to access it outside a postback. Can MVC do this?
I do not believe this is possible. There is no way to interact with Session object outside of some form of postback.
You may want to architect your solution as such that you can mitigate the need to go to a different page and return.
The adding/editing portion of your form could instead be handled through asynchronous web POSTS independent of your main form. JQuery UI's dialog window and UI Tabs come in nicely for sophisticated forms that need CRUD capabilities to other components of your web application.
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
I have an ASP.net webforms app that connects to a web service, All the functionality is on one page that has lots of difference states and I use a multi view to display the correct html depending on the current state.
The problem is the page is huge and unweildly. The code behind isn't so bad but the aspx page is just out of control.
I would like to have a seperate page for each possible state but can't find a good way to move and pass data between pages. Are there any patterns or practices that I can implement that can help with this? And if having a page for each state is not the way to go what else can I do?
I have to stick with the webforms platform :( so i can't move to MVC.
You need to look into Cross Page Posting. This will allow you to postback to a different url and still have access to the previous page's controls. It will make the separation of your different views much easier to manage.
You could create a custom control for each of your states and then programmatically instantiate the appropriate control and populate the properties at runtime.
Use user controls or custom controls to reduce the page weight and improve maintainability of your web forms.
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.
For example,
If I have a textbox with runat=server on a page, The value will be posted back to the server so I can access the properties in the code-behind.
However, under the following situations, does it still hold true?
A textbox with runat=server but does not appear in the function that is post back to. For example, a button is also on the page, when clicked a post back occurs and within the method that is raised, this textbox was not used.
Within a MasterPage, will a textbox residing on the Masterpage itself be posted back?
Because just thinking, isn't this mechanism bloated in nature?
If all input controls and its value are posted back on every single button click (even when the input control is not needed), doesn't this deteriorate performance?
Having just one Form Tag on the page really restricts us to using this mechanism?
Truly Understanding ViewState is a must read article on the subject of ASP.NET ViewState
There are several options to cut down on the bloat (and yes, there's a lot of it when dealing with lots of controls):
Use AJAX to post only the items required - although be careful to allow clients that don't have JavaScript enabled to still use the page/ site.
The MVC framework allows multiple form tags to be used so you can group sections if needs be.
Set the EnableViewState to false on pages/ controls.
Break up your pages into smaller ones.
Additionally, check out this brilliant graphical representation of the Page Life Cycle in ASP.NET.
Every input on the page is posted back fully unless you use ajax, because of the single form tag. Welcome to asp.net...
As long as the method that you're hitting on the server-side is a non-static member of the page's class, it'll have access to the textbox and all other controls on the page.
And yes, all controls rendered to the browser (whether in the MasterPage, user control, etc.) will be available on post-back.
You may want to look into Understanding ASP.NET View State.
There surely are performance hits with this architecture, but (depending on complexity of the page) it's usually not an issue from the server load perspective, because hardware upgrades are typically cheaper than additional programming hours spend on optimizing application performance.
With that said, (and as others have pointed out) look into using AJAX if you want to avoid whole page-level postbacks to the server.
Yes, it's all posted back, and yes it can cause bloat. I'm sure if you search for ViewState you will find plenty of people ranting about it and how to minimise it :)
Yes your text box will be available in both cases, yes it is bloated. This is where AJAX comes into play. Using AJAX you can send just the data you need.
If you want to send a minimal ammount of data, you could use a Page Method (static method on page decorated so the script manager builds javascript to call it or you could call it using jquery or other methods), or a script enabled web service works nice as well.
You also have viewstate which can get very large. ASP.Net MVC is a new paradigm instead of using WebForms which doesn't have view state, or post backs. It embraces HTTP instead of hidding it giving developers more control.
The textbox data would be posted back as noted. In addition to using Ajax, disabling view state greatly imporoves your page's performance though even then data in properties critical to the functioning of controls (Control state) would still be posted back.
If you didn't have postback for every control on the form, you wouldn't be able to access it in code-behind. I.e. if in your button press you wanted to modify the property of the text control you couldn't do that because ASP.Net would know nothing about the text control.
Since the communication between the server and the client is stateless and every time a page is server the server forgets all about it Postbacks are important if you want to work with the same page again. No matter what programming language you use, this or similar mechanism exists for processing server side code.
If you wish to minimize postback (viewstate size), do this.
Set enableviewstate=false on all controls that you don't want posted back.
Use AJAX and web services wherever possible (and don't use UpdatePanel).
Use HTML control as much as possible instead of ASP.Net controls.
Hmm.. There are some excellent suggestion in other answers and good links too.
You've pretty much hit the nail on the head with vanilla ASP.NET - it's not very good! In both the instances you describe the answer is yes - the textbox will be sent with the form.
The whole postback/ViewState problem is a bit of a pain, one of the first things any competent ASP.NET developer learns to do is avoid them!