Very simple questions as “How can I programmatically set my Page’s title from codebehind?” or “How can I handle my Page’s <head> element from codebehind?” were, are and will be asked about every single day in the public newsgroups, forums, etc.
This is because v1.x doesn’t include any built-in support for handling the <head> element or any of its children elements.
This leads to the common approach of adding the runat=’server’ attribute to the <head> element and then handling it as a HtmlGenericControl. Pretty simple and pretty unfriendly stuff at the same time. In addition, having VS.NET removing the attribute at will just make things more annoying.
After looking at all the feedback from newsgroups, forums, etc, it was pretty obvious that something was needed. Because of this, the HtmlHead control was born in the PDC03 bits (and others like HtmlTitle and HtmlLink did appear in the March04 bits). The Page type itself was modified to include these additions and new properties were added: Header (in the PDC03 bits) returns an instance of a type that implements IPageHeader (HtmlHead in this case) and Title (in the March04 bits) just wraps a Header.Title call.
So now, this is how you handle this very common need in the Whidbey bits:
void Page_Load (object sender, EventArgs e) {
this.Header.Title = “This is a title”;
this.Header.LinkedStyleSheets.Add (“classicblue.css”);
this.Header.Metadata.Add (“author”,”clarius”);
}
Pretty simple, ugh? No doubt, this is a good addition. Hopefully all the confusion and how-to questions that plagued the newsgroups about how to deal with this in v1.x won’t be there for v2.0 (now that’s a wish).
While playing with this new supported I discovered a few “issues” that I describe in these posts (warning: the following info may be more than you ever wanted to know about <head> and its child elements):
Whidbey Support For HtmlHead, Part I – What title will be rendered?
Whidbey support for HtmlHead, Part II – Not only VS.NET messes up your markup
Whidbey support for HtmlHead, Part III – The missing ViewState
The third interesting observation worth noticing from HtmlHead and co. (that is, HtmlLink, HtmlHead, etc) is that they know nothing about state management… viewstate? what’s that??
The PDC03 bits didn’t include any state management code and the March04 bits still haven’t changed this. Bottom line: if you’re planning to dynamically alter the page title, the links or metadata elements you’re definitively out of luck (well… you can always implemented the code yourself…).
Let’s take for instance the HtmlTitle control: it’s a very simple (really, very simple) control that derives from HtmlControl overriding only two methods (AddParsedSubObject and Render) and adding a property named Text.
The get and set accesors for the HtmlTitle.Text property read and write a private member variable instead of using viewstate as its storage; any changes made will be lost on postback.
The same holds true for metadata and links elements, any modifications made at runtime are lost on postback.
All this new support for the head and its child elements is really a very welcomed one, but won’t be of much use without state management implemented. Let’s just hope that state management for these controls is already planned but not there only because March04 is not a feature complete build.
