My musings about .NET and what not

Moving ASP.NET Hidden Fields to the Bottom - The EASY Way

Perhaps you've seen complex solutions for moving ASP.NET-generated hidden fields (__EVENTVALIDATION, __EVENTTARGET, __EVENTARGUMENT, etc...) to the bottom of the form. Forget it. Here's the easy way to do it -- in a single line of code.

This article is inspired by a recent blog post at Sb2DevelopersBlog, where my friend Yoann writes about moving hidden fields for event validation to the bottom of the page using a heavy-duty custom HttpModule. As Yoann points out, this can be helpful for search engine optimization, as the crawler can parse your content without having to wade through a ton of gobbledygook first.

The solution he presents is actually quite clever, but pretty complicated. I've seen others as well, like those which involve overriding the Render method and using regular expressions to match the hidden form tags. Again, too complicated.

Did you know that, with the release of the .NET Framework 3.5 SP1, there's a much, much easier way?

In your application's configuration file (web.config):

<pages renderAllHiddenFieldsAtTopOfForm="false">

Yeah, that's it. Seriously. But before you go doing this, you might want to read a little bit further...

Is This a Good Idea?

Maybe, maybe not.

As pointed out, moving hidden fields to the bottom can help searchbots index your content more easily, and will also make the client-side rendering a bit quicker too, both of which are big plusses.

But, as with many optimization techniques, there's a potentially serious downside as well. You see, there's a good reason ASP.NET 3.5 renders hidden form fields at the top by default. By doing this, it ensures that all the information in these fields gets posted to the server in case if a user get impatient and tries to post the form before the page finishes loading. In the case where these hidden fields are rendered at the bottom, if a postback is performed before the page fully loads, it will usually cause the following error:

Invalid postback or callback argument.

This can be especially troublesome in AJAX scenarios, or when using third-party controls that render hidden fields of their own. The only way I know of to determine which pages might cause trouble is to test them individually and see what happens.

Take Note

There are a few other things you'll want to keep in mind when using this property:

  • Even though the property is called "RenderAllHiddenFieldsAtTopOfForm," it won't affect hidden fields that you create, only system-generated ones.
  • This property is applied to all the site's pages, and can't be overridden at the page level.
  • I've done a bit of experimenting and as far as I can tell, the __VIEWSTATE hidden field still renders at the top of the form, regardless of the property's setting.
  • This is supported by .NET Framework versions 3.5 SP1, 3.0 SP1, and 2.0 SP1.

Hopefully, those of you who are interested in overriding ASP.NET's default hidden field behavior will find this information useful.

Subscribe to this blog for more cool content like this!

kick it on DotNetKicks.com

shout it on DotNetShoutOut.com

vote it on WebDevVote.com

Bookmark / Share

    » Similar Posts

    1. Defensive Programming, or Why Exception Handling Is Like Car Insurance
    2. 10 Reasons ASP.NET Webforms (Still) Rock
    3. Integrating Exception Handling Into the Development Cycle

    » Trackbacks & Pingbacks

    1. You've been kicked (a good thing) - Trackback from DotNetKicks.com

      Moving ASP.NET Hidden Fields to the Bottom - The EASY Way — December 1, 2008 6:05 PM
    Trackback link for this post:
    http://leedumond.com/trackback.ashx?id=28

    » Comments

    1. Yoann. B avatar

      Hi !

      Just founded your post on DZone, thanks for your tips after mine.

      This is more simple than my approach, but still keeping the ViewState Hidden Field in top of Form.

      However, i think that as you said it's not a really good thing to put the other Hidden Fields (__eventvalidation etc..) to bottom of page.

      Yoann. B — December 2, 2008 12:41 PM
    2. Yoann. B avatar

      Back with new informations about your trick.

      After a Quick Reflector on that Web.Config Property, this method might be pretty slower than my http filter approach. Here the internal HtmlForm.RenderChildren() that use RenderAllHiddenFieldsAtTopOfForm web.config property.

      HttpWriter innerWriter = writer.InnerWriter as HttpWriter;

      if (((page != null) && (innerWriter != null)) && RuntimeConfig.GetConfig(this.Context).Pages.RenderAllHiddenFieldsAtTopOfForm)

      {

      innerWriter.HasBeenClearedRecently = false;

      int responseBufferCountAfterFlush = innerWriter.GetResponseBufferCountAfterFlush();

      base.RenderChildren(writer);

      int srcIndex = innerWriter.GetResponseBufferCountAfterFlush();

      page.EndFormRenderHiddenFields(writer, this.UniqueID);

      if (!innerWriter.HasBeenClearedRecently)

      {

      int num3 = innerWriter.GetResponseBufferCountAfterFlush();

      innerWriter.MoveResponseBufferRangeForward(srcIndex, num3 - srcIndex, responseBufferCountAfterFlush);

      }

      page.EndFormRenderArrayAndExpandoAttribute(writer, this.UniqueID);

      page.EndFormRenderPostBackAndWebFormsScript(writer, this.UniqueID);

      page.OnFormPostRender();

      }

      The 3 call of GetResponseBufferCountAfterFlush might bring peformances down on lot of requests ...

      Hope this help's! :)

      Yoann. B — December 2, 2008 1:08 PM
    3. Abhilash avatar

      Hi,

      I came across Microsoft Connect, where they clearly states that the search-providers indexes the page completely instead of first few-segments(512 bytes). Hence, moving the viewstate has nothing to do with Search Engine Optmization.

      Have a look at the link: connect.microsoft.com/.../ViewFeedback.as

      Thanks.

      Abhilash — October 17, 2009 6:55 AM
    4. Lee Dumond avatar

      @Abhilash --

      I just ran across that Microsoft Connect article. They confirm what I stated in my post -- that the the reason hidden fields render at the top is to prevent problems with early postbacks.

      They also mention the tidbit about the location of the ViewState having nothing to do with how searchbots index the page, which quite frankly was news to me. ;) I'm going to devote a separate blog post to that soon.

      Lee Dumond — October 22, 2009 3:36 PM

    » Leave a Comment