WEBINAR: On-demand webcast
How to Boost Database Development Productivity on Linux, Docker, and Kubernetes with Microsoft SQL Server 2017 REGISTER >
This article tries to highlight a few useful attributes/properties of ASP.NET controls.
The ID's that get auto-generated for the ASP.NET controls when they render, are known to cause trouble and annoyance when we have to refer them in the client scripts. Although, this auto-generation is a simple concatenation of the naming container and the id, the ids generated are still not predictable to a good extent.
ASP.NET 4.0 addresses this issue with the ClientIDMode property. It lets you control the way these ID's are generated. The ClientIDMode takes one of the four possible values. Viz. AutoID, Static and Predictable and Inherit.
Below is a brief explanation of what the modes mean:
- AutoID - This behavior causes the generation of Id's as per the versions prior to 4.0.
- Static - This behavior causes the Id's that you specify to be retained. There would be no change in them when they are rendered.
- Predictable - This behavior lets you specify a suffix that would be merged with the ID property of the container control.
- Inherit - This behavior lets you inherit the settings as the parent control.
Note that the default ClientIDMode for the Page is AutoID and for the control is Inherit. You can set the ClientIDMode value through the Page attribute.
You set the page-level value in the @ Page directive. You can also do this for all the pages of your application by modifying your web configuration file.
<system.web> <pages clientIDMode="Predictable"></pages> </system.web>
2. Meta Keywords and Meta Description
The Page class adds two new properties in ASP.NET 4.0 - MetaKeywords and MetaDescription. These two properties can be set at run time, and can be driven through database or any other source.
You can set these properties at run time, which lets you get the content from a database or other source, and which lets you set the tags dynamically to describe what a particular page is for.
The following Page markup shows you the two attributes in action.
<%@ Page Language="C#" AutoEventWireup="true" Keywords="keyword1, keyword2" Description="my description" %>
3. Persisting Row Selection in Data Bound Controls
Data bound ASP.NET controls like Grid View support row selection. But they would select the same numbered row on every page of the control. Persistence in row selection is missed. That is because versions prior to ASP.NET 4.0 selected the row on the subsequent pages based on the row index. The new version of ASP.NET provides us an Intuitive way of solving this issue.
The data bound controls now support an EnablePersistedSection property which helps us achieve this. Following markup shows us the EnablePersistedSelection property used in the List View control.
<asp:ListView ID="topRanks" runat="server" EnablePersistedSelection="True" DataSourceID="dsRanks" DataKeyNames="rankid"> <ItemTemplate> … </ItemTemplate> <SelectedItemTemplate> … </SelectedItemTemplate> </asp:ListView>
One of the less used but better known attribute of ASP.NET is AutoEventWireup. In simplest terms, it allows the calls to the page events automatically without the use of explicit delegates when set to true.
The following markup shows the usage of AutoEventWireup attribute:
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" …. %>
Its default value is true. The primary disadvantage of the usage of AutoEventWireup attribute can be read from the MSDN page that talks about the Control Event Model: "This limits your flexibility in how you name event handlers. Another disadvantage is that performance is adversely affected, because ASP.NET searches for methods at run-time. For a Web site with high traffic volumes, the impact on performance could be significant."
5. Header Property of Page
The Page class now provides us the Header property. You can bind this now at runtime. The following sample code shows you how to explicitly set the Title property.
this.Header.Title = "My page title";
This property comes in handy, when you have to dynamically associate a style sheet based on a rule. Printing a page is an ideal candidate for this situation.
HtmlLink printLink = new HtmlLink (); printLink.Attributes.Add ("type", "text/css"); printLink.Attributes.Add ("rel", "stylesheet"); printLink.Attributes.Add ("href", "css/print.css"); this.Header.Controls.Add (printLink);
6. AssociatedControlID Property
You can associate one control to another server control in a web form. This can be done using the AssociatedControlID property of the server control. This is useful in cases where you want to set the hotkey for an associated control based on some action.
The default value for this property is an empty string, which indicates that the control is not associated with any other server control on the web form. The following markup shows how a Textbox is associated with the Label server control.
<asp:label ID="lblUserName" AssociatedControlID="txtUserName" runat="server" Text="User name:" /> <asp:TextBox ID="txtUserName" runat="server" />
7. ControlState Property
One of the most important ASP.NET's state management technique is the ViewState. It allows you to preserve values between round trips to the webserver. But since this can be turned off at the parent level, this was not a reliable method to store information.
ASP.NET 2.0 introduced the private ViewState for a server control called the "ControlState". This can be used to store critical information of a control and ASP.NET would take care of the serialization and deserialization of this.
Note that, this has to be used judiciously as it can affect the performance of the page. Look at the references section for an excellent article on how to use this.
Rick Strahl has an implementation that provides us an alternative against the conventional view state usage. It has a PreservedProperties collection that holds the control id and the property name. Look at the references section for the link to "Implementing an ASP.NET PreserveProperty Control"
9. Browser Based Properties?
ASP.NET version 2.o provides us a way to specify the browser filter for a property. I stumbled on this fact when I hit the Ryan Farley's blog. He too stumbled on this when he hit the John Katsiotis's page.
The fact is that you can set a different value for a property based on the browser. Look at the example below: (from Ryan Farley's blog)
10. PreviousPageType Directive
The PreviousPageType directive is part of the ASP.NET 2.o Cross-page postback mechanism that allows you to specify the virtual path of the source page for strongly typed access to the source page.
The posted data would be normally accessed through the PreviousPage property and the FindControl method which involved a cast. However, using the strongly typed PreviousPageType directive lets you access the public properties in the strongly-typed manner without a cast. There are no FindControl methods to be called too.
For e.g, Let's say you have a page called "firstpage.aspx" that has a public property called "FirstProperty". Now, in your second page, say "secondpage.aspx" you would need to add the directive to the page like:
<%@ PreviousPageType VirtualPath=" firstpage.aspx" %>
And then called the property of the firstpage like this:
var firstPageProperty = PreviousPage.FirstProperty;
Thanks for reading!
ReferencesImplementing an ASP.NET PreserveProperty Control
ASP.NET Web Server Control Event Model
ControlState Property Demystified