Form Elements in ASP.NET Master Pages and Content Pages

Thought I would review some of my outstanding questions and see if I can close some of them off.

This one was an interesting one. I outright refused to believe you can only have one form on an ASP.NET page. This to me made no sense. I have seen plenty of webpages that have more than one form on a web page, why should an ASP.NET page be any different?

So, it got me thinking.

Why does a ASP.NET page need a form element?

ASP.NET pages try to emulate the WinForms environment, by provided state persistance through the PostBack model. This provides an element of state to a stateless environment. In order to do this, the runtime needs to be able to have the ability to maintain this state within each "form". It does this by posting back data to itself. It's important to note that:

• There is nothing really fancy about a PostBack.
• It uses a HTTP form and POST, the same as any other form, from any other stack.
• Just because it looks like it might be doing something special, its not, all that happens is it POST's back with some info about what caused it, so you can do things like handle client-side events, in server-side code.

So why only one?

This to me was the million pound question (I am British). I understand that ASP.NET needs this, especially if you are using ASP.NET server controls, but why the hell can't I make my own additional forms?

So, I thought screw it, just make your own form!

And I did. I added a bog-standard, simple form with a submit action of "#". This then performs a POST to the current page, with the Form data for the given form in the request.

Guess what? It all worked fine. So I ended up with:

• A master page, with a HTML form in
• This form posts back to the current page (basically the page using the master).
• In the Page_Load code-behind for the master, I then added code to check the request to see what data was passed in the request. If it contains data (say a hidden field) then I know the post was sourced from the Form on the master page, if not, then it is most liekly a PostBack from content, and can be ignored.
• I then surrounded the Content tags with <form runat="server" id="aspNetForm"...> </form> tags. This meant that all content pages automatically had a form to work with.

This provided me with a relatively simple, clean solution to my problem. My login form works fine in tandem with all the content forms created, some of which are complex forms, others use lots of server controls and many PostBacks, and so on.

I hope this helps others.

the form tag itself is in the MasterPage, as such, you can code any asp.net server controls onto the master page that you wish. And you can write up the processing logic for those server controls on the master page's code behind file.

So, in your example, you can have the login controls on the upper right of the master page, and then have the authentication logic in the code page for the MASTER PAGE, not your content page.

This allows you to have the login controls on every page, and maintain that processing, as well as maintain the content controls and their processing on their individual pages.

Everyone else has already mentioned that you can only have a single form element in a given ASP.NET page, and that it would be contained in the master page. So far, so good. But I don't think that helps you get fully where you want to be ...

In your master pages, you've (I assume!) defined asp:ContentPlaceHolder controls. Your pages which use the master then have corresponding asp:Content tags. All your page content must go in these corresponding asp:Content tags.

Once in that tag, they are part of the master page's form. The master page can respond to events from its own controls, and the pages themselves respond to events from their own controls, and you're set.

If you need the page to interact with the master page, you can access it via the Page.Master property. To interact with any publicly-visible code (methods, properties, etc.) from the master page, you'd cast this property to the correct type, and access the publicly-visible code from there.

That should get you where you need to be in this scenario. (It's worked for me on multiple sites!)