views:

278

answers:

3

i have a search form on every page, hence i put it on the master page. after adding runat=server to that form i am now unable to use other forms that runat server ;)

how do people usually get around this?

one idea is to surround the whole page with one form runat=server but then i have to have the code in the master page even for those forms that are used on only one sub page (like contact for example).

how do people usually get around this?

thnx

+1  A: 

First question is, why do you want to have multiple runat="server" forms?

You can still have forms without runat="server" on the page, or use the PostBackUrl property on Button controls, to post to different ASP.NET pages.

To collect data in a multi-step process, you can either look at the ASP.NET Wizard control, see Scott Guthrie's blog post here.

Alternatively you can manage it all yourself and use ASP.NET Panels, or use the already mentioned PostBackUrl to navigate from ASP.NET page to a different page.

Wim Hollebrandse
well (not really sure what exactly you are referring to - why do you want to WHAT?) - i have to do some complex parsing for the search and then go to the next page. also for the contact (for example) i want to do some stuff like db insert maybe and then go to the next page.
b0x0rz
ah, ok (after edit). well i don't want to :) just not sure how then to separate the code for two forms. one should be on master page since it is always used, the other on the single page (since it is only used there). Abel (on this page) mentioned that it is ok to have all the code on the master page even though the second form will only be used on one sub page.
b0x0rz
With *"all the code"* I meant the `<form>` tags. It's customary to have them in the Master, simply because you'll have to have them anyway (provided some exceptions). Personally, I often use a two-level Master: a clean form-less Root Master, and several sub-Masters that inherit from the Root Master (masters can be nested). That way I can decide per-page what I need, without loosing any flexibility. It depends on your situation what's eventually most appropriate.
Abel
+2  A: 

This has often been considered one of the most problematic design decisions on ASP.NET. It's a sad thing that you're kinda fixed to this one-form-per-page principle.

One reason that you may want to have multiple forms is that the default button will be set by the browser to the submit button. Someone typing into your search box and hitting enter should not submit the main form (suppose that's the login page), but the tiny form of the search button.

The easiest and "standard" way to work around this is using an asp:Panel and set the DefaultButton property. This should wrap around the part that includes both the search fields and the search button.

Don't worry about coding the <form> from inside the masterpage, surrounding the whole page. That's a common design. Most server controls require a form, so why not simply include it regardless: it is supposed to be there.

Abel
i see. i just thought that it is wrong to code the form that will be on one page in the master page. somehow does not sit well with me :P but as you said it's common design, perhaps i should. thnx.
b0x0rz
In the beginning of ASP.NET, it has often been frowned upon to why MS chose this design of having one-and-only-one form per page. It has advantages (simplicity favors complexity) and disadvantages (certain traditional approaches need rethinking). There are also workarounds, but all-in-all my advice would be: stick to this design and use its features and only start building "non-default" design patterns when you really must and perfectly understand its consequences.
Abel
+1  A: 

I'd suggest you to have search html form w/o runat=server on the master page, like

<form action="Search.aspx" method="get">
  <input type="text" name="q" /><input type="submit" />
</form>

Use method=get to have possibility take URL of the search. And then do whatever you need with the query in codebehind of the Search.aspx:

public void Page_Load(object sender)
{
  string q = Context.Request.QueryString["q"];
  /*...*/
}
Petr Felzmann