Forums (Obsolete)

Member

bdrenner-new42 - 2/5/2014 10:40:35 AM

Necessary usage of <form> on master page

The documentation on master pages says to include the form element on the master page, and to nest the pclManagers, ToolkitScriptManager, CMSPortalManager, and CMSMenu inside that form. Is it necessary to enclose these elements within a form? Beyond that, why include the form element on the master page?

Web Forms allows multiple form elements on a single page, even if only one can `runat="server"`, but I don't believe HTML can nest forms inside of forms.

Member

kentico_sandroj - 2/6/2014 2:26:38 PM

RE:Necessary usage of <form> on master page

Hello,

Web Forms allow only one form tag on an aspx page:

Note: An .aspx page can only contain ONE <form runat="server"> control!

This is an ASP.NET restrictions which is not specific to Kentico. A workaround may be using iFrames or creating a custom control that is processed by .NET when submitted.

Please let me know if you have any questions.

Best Regards,
Sandro

Member

bdrenner-new42 - 2/6/2014 3:14:37 PM

RE:Necessary usage of <form> on master page

Thanks for your help, but this doesn't answer my questions.

The W3Schools quote is saying the same thing that I was saying: A web form can have only one of these...

<form runat="server">

...but beyond that, you can include as many of these as you want:

<form action="wherever">

However, by wrapping entire pages inside `<form runat="server">` via the master page, you can no longer use multiple forms, because HTML standard doesn't allow them to be nested. To restate my questions:

- Must the following controls be inside a `<form runat="server">` in order for Kentico to function correctly?: pclManagers, ToolkitScriptManager, CMSPortalManager, and CMSMenu

- Is it necessary to place the `<form runat="server">` on Kentico master pages?

Member

kentico_sandroj - 2/6/2014 3:31:48 PM

RE:Necessary usage of <form> on master page

Hello,

Sorry if I misunderstood and thank you for the clarification. Unfortunately, the answer to both questions is yes. You must include the Kentico controls inside of <form runat="server"> and it is necessary to have that tag on your master page. I apologize if this is an inconvenience for you. However, as I mentioned previously, you can nest tags by using iFrames or use the suggested workarounds in the linked post.

Please let me know if you have additional questions.

Best Regards,
Sandro

Member

mrowland-wildfireideas - 3/8/2014 11:29:56 AM

RE:Necessary usage of <form> on master page

This is unfortunate. Having all of your markup nested inside a <form> tag is a terrible front end implementation. Not only is it semantically invalid HTML, it wreaks havoc with front end frameworks. You should really consider an alternative approach if you intend to have Kentico work as a CMS for modern responsive web sites.

Kentico Legend

Brenden Kehren - 3/13/2014 2:22:23 PM

RE:Necessary usage of <form> on master page

@MROWLAND-WILDFIREIDEAS, the form tag is required function of ASP.NET and not a Kentico restriction as Sandro stated. Also, Kentico is running many, many modern responsive websites without a problem.

What exactly are you trying to accomplish? Maybe post some of your markup. Or go back to your front end developer and tell them you need this to be compliant with an asp.net website.

If you need to perform some actions on a button click or other event then simply do so in your code behind. Sandro suggested iframes but unless the page in the iframe is running on the same website, I don't use them, for security reasons.

Member

mrowland-wildfireideas - 3/13/2014 2:32:56 PM

RE:Necessary usage of <form> on master page

The current implementation on the site I'm working on, Kentico wraps the entire page markup in a form tag.

<html>
<head></head>
<body>
<form>
[...all of our CMS output, front end code, etc. ..]
</form>
</body>
</html>

If the form element is required by ASP.NET, is there no way to have it NOT wrap the entire page output? I don't mind if it is on the page, but having it wrap all front end output is a problem for any front end framework.

The site I'm working on will be one of the many modern, responsive sites you mentioned and Kentico is working fine as a CMS, but we'v had to hack around this form element issue in a way that is not semantic or proper front-end code. Just because there is a way to make it work doesn't mean it is correct.

If there is an alternative way (besides iframes) to deal with the required form tag I would really like to hear it. Thanks,

Member

bdrenner-new42 - 3/13/2014 2:41:56 PM

RE:Necessary usage of <form> on master page

mrowland-wildfireideas,

My workaround was to place two additional ContentPlaceHolders on the master page: one just before and one just after the required form. Page templates can then provide content that is rendered outside of the form. It's crappy, but it works. You can treat the Kentico-required form as an invisible "wart".

Obviously ASP.NET does not require you to have a <form> at all, much less on a master page. *facepalm*

Member

mrowland-wildfireideas - 3/13/2014 2:45:22 PM

RE:Necessary usage of <form> on master page

bdrenner-new42 wrote: mrowland-wildfireideas,

My workaround was to place two additional ContentPlaceHolders on the master page: one just before and one just after the required form. Page templates can then provide content that is rendered outside of the form. It's crappy, but it works. You can treat the Kentico-required form as an invisible "wart".

Obviously ASP.NET does not require you to have a <form> at all, much less on a master page. *facepalm*

:-) Thanks! I will attempt to give that a try. Is it possible to do this method via only portal engine development?


Member	bdrenner-new42 - 3/20/2014 9:57:01 AM RE:Necessary usage of <form> on master page That's a good question, and I'm not sure. Please let me know if you figure out a way.

Kentico Legend

Brenden Kehren - 3/19/2014 7:41:48 AM

RE:Necessary usage of <form> on master page

bdrenner-new42 wrote: mrowland-wildfireideas,Obviously ASP.NET does not require you to have a <form> at all, much less on a master page. *facepalm*

ASP.NET server controls offer a richer programming experience than HTML elements. If you plan to have any asp.net controls on a page and have any actions work with them, the < form > tag is required otherwise it would simply be an HTML page vs. an .ASPX page. It is also required that all asp.net controls be rendered in the same < form > tag. With this being said, if the master page does not have a < form > tag on it and you have content pages being loaded using that master page or have dynamically added controls to your pages (like Kentico does), your pages will not work. You might take some time and read up on asp.net.

Member

bdrenner-new42 - 3/19/2014 10:28:21 AM

RE:Necessary usage of <form> on master page

Indeed, it is a Web Forms convention to place the magic `<form runat="server">` on the master page, and some server controls are required to be nested inside it. However, not all server controls must be in the magic form - only those that abstract HTML-native form elements. For example, the following works just fine:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="WebApplication1.WebForm1" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
	<asp:ObjectDataSource runat="server" />
	<asp:Literal runat="server">
		Literal works.
	</asp:Literal>
	<asp:PlaceHolder runat="server">
		Placeholder works.
	</asp:PlaceHolder>
	<asp:Label runat="server" />
	<asp:Table runat="server">
		<asp:TableRow>
			<asp:TableCell>column A</asp:TableCell>
			<asp:TableCell>column B</asp:TableCell>
		</asp:TableRow>
	</asp:Table>
</body>
</html>

Given IDs, the code-behind can manipulate those server controls. Custom server controls and user controls can similarly live outside of the magic form, with the limitation that they don't nest the particular server controls that should be inside it.

Regarding those server controls that depend on `<form runat="server">`, Adam Freeman recommends against using them. In his book, Pro ASP.NET 4.5 in C#, he wrote "We don’t use them, we don’t think you should use them, and we believe they run counter to the development style that produces robust, maintainable, and testable Web Forms applications."

The favorable alternative to using those controls is to use Page.TryUpdateModel with Page.ModelBindingExecutionContext. Otherwise use "code nuggets" to render values from code-behind methods whose parameters are decorated with model-binding attributes (such as FormAttribute, RouteDataAttribute, QueryStringAttribute, etc.).

But then again, to quote from Freeman's book, "Rich UI Controls are not all bad. They can be used by less-experienced developers to create basic web applications without requiring a detailed knowledge of HTML and CSS." Given the apparent target audience for the Portal Engine, it makes sense that Kentico went this route. Also, System.Web.ModelBinding is a recent addition to the Web Forms arsenal.

Kentico Legend

Brenden Kehren - 3/19/2014 6:34:52 PM

RE:Necessary usage of <form> on master page

Quote all you would like it still doesn't change the fact that Kentico is a standard asp.net website that uses more than the standard server controls on every page. I will guarantee you will not find any robust, enterprise asp.net website that does not take advantage of a control that will not require a < form > tag. Something as simple as a button will require you to have the < form > tag.

If you don't want free assistance, that's fine, just say so. I'm simply trying to help find the specific problem and solve it. What you've failed to provide is the specific problem (not that there is a < form > tag on the master page) you are trying to overcome. Look at my last post, give specific details as to what you are attempting to do and I'll attempt to provide a solution and not a hack.

Member

bdrenner-new42 - 3/20/2014 9:49:23 AM

RE:Necessary usage of <form> on master page

Froggeye, I apologize if I have offended. Sandroj answered my question satisfactorily. My intention was to clarify my previous comments in the interest of factual accuracy. I very much appreciate the assistance I receive on this and other forums.

Mrowland, TL;DR: Wrapping the whole page in a form is a convention from earlier versions of Web Forms. Web Forms and the broader ASP.NET Framework no longer require or encourage this practice, according to published authorities. However, Kentico understandably still adheres to the old convention. My workaround applies, but I am uncertain which, if any, Kentico controls work outside the form.

Kentico Legend

Brenden Kehren - 3/19/2014 7:54:57 AM

RE:Necessary usage of <form> on master page

mrowland-wildfireideas wrote: The site I'm working on will be one of the many modern, responsive sites you mentioned and Kentico is working fine as a CMS, but we'v had to hack around this form element issue in a way that is not semantic or proper front-end code. Just because there is a way to make it work doesn't mean it is correct.

What is the exact problem you are having? Meaning what is the workaround or HACK you are having to put in place? My guess is since you're used to front end programming you are use to using HTML controls and don't know what the ASP.NET equivalent is.


Member	mrowland-wildfireideas - 3/19/2014 7:57:52 AM RE:Necessary usage of <form> on master page I described the exact problem above. All page output wrapped in a <form> tag. Nightmare for front end implementations.

Kentico Legend

Brenden Kehren - 3/19/2014 8:07:38 AM

RE:Necessary usage of <form> on master page

That's the general problem. What's the specific problem or what isn't working that caused you to search/discover the form tag being placed on the master page?

For instance you're trying to use jQuery to get an ID of textbox but the textbox's ID keeps changing and therefore you cannot apply a style or function to the textbox.