When I speak at conferences and classes, I often receive questions about the use of hidden fields in ASP.NET (although the questions are rarely asked publicly…). As a matter of fact, hidden fields do have a bad reputation among web developers (including ASP developers). It seems that their use makes the developer feel less smart because he or she is unable to find a better solution. A similar feeling was common among Windows SDK programmers in regards the use of global variables or temporary files. I do know dozens of enterprise-wide applications that owe their health and ability to work to humble but effective temporary files.
Speaking of ASP.NET hidden fields, though, another more subtle point comes up. It also seems that developers fear using hidden fields just because of the dazzling new object-oriented world of ASP.NET. They think that in a technologically advanced world, resorting to such an old-fashioned and poor instrument is certainly deprecated and deplorable. Where’s the truth?t
The truth is that ASP.NET is, first and foremost, an excellent abstraction layer built on top of HTTP and HTML. No matter the bells and whistles that refine the programming interface (easy-to-use objects, ad hoc methods, events), the underlying substrate is still the old faithful HTML markup with a bit of script. In this context, hidden fields are still the only way that browsers and web servers have to exchange data. So nothing really prohibits the use of hidden fields in ASP.NET applications, and using them is in no way shameful, as long as HTTP remains the underlying protocol.
ASP.NET does provide more effective tools to save data in a page request—for example, the view state mechanism. If you want to use a hidden field within an ASP.NET page, you have two options. First, you place the <input> tag in the markup, set the runat attribute, and assign it a dynamically generated text. Second, you generate the input field programmatically using the RegisterHiddenField method on the Page class. When you call this method, you specify the name and the content of the hidden field. The <input> tag is not generated instantly, however, and you can’t further program against it the next line. As the method name suggests—RegisterHiddenField—a field with that name and content is registered with the page. Later in the request processing, when the page generates the markup for the browser, all the elements registered with the page originate their markup. RegisterHiddenField, as well as all others RegisterXXX methods on the Page class, simply creates an entry in an internal collection with the information about the HTML tag (or the script) to create. These collections are processed and emptied during the rendering phase of the page.
Instead of using a hidden field, you can more effectively use the ViewState.
Any value you associate with the page through the view state will then be returned
on the next postback. Admittedly, this solution works great if you need to associate
unique values with a page. In other situations, for example when you need to
pass information to be consumed through client-side script, hidden fields are
not just an effective solution—they are the only choice you have.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].