There are various expression types in ASP.NET, each serving a particular scenario and providing a specific capability. An ASP.NET expression is any executable piece of code you can write in the .aspx file wrapped by <% ... %> tags. Introduced with classic ASP, <%...%> code blocks indicate code to execute in place with the results to be incorporated locally in the page response. ASP-style code blocks, though, were designed for an interpreted environment like ASP, and don't easily fit in the compiler-based and object-oriented world of ASP.NET.
For this reason, ASP.NET 1.x supports data binding expressions, characterized by <%# ... %>. You can use data binding expressions to assign calculated values to control properties in a declarative manner. The drawback of these expressions is that they require an explicit data binding step to kick in and do their own job. In other words, each control that uses a similar expression must have the DataBind method called to trigger the process that will assign a value to the expression. Aside from the need of calling the DataBind method in the Page_Load event handler, this model works just fine in ASP.NET 1.x and to some extent also in ASP.NET 2.0.
In ASP.NET 2.0, pages using data source controls can't properly leverage data binding expressions to set properties declaratively. Let's briefly consider a page that incorporates a SqlDataSource control and a GridView, exactly in this order. If you use a data binding expression to, say, retrieve the connection string from a separate storage medium (i.e., the web.config file) and you call DataBind, all works just fine. Being the first control in the page, the SqlDataSource is fully initialized when the GridView enters its initialization stage and can provide data as needed. What if you revert the order of the controls in the page and move the GridView up in the hierarchy?
<asp:GridView id="grid" runat="server"
datasourceid="SqlDataSource1" />
<asp:SqlDataSource id="SqlDataSource1" runat="server"
ConnectionString=
<% #ConfigurationManager.ConnectionStrings[...]
%>
:
/>
You would reasonably expect that the page work as usual. But, interestingly enough, this is not what happens. Let's see why.
The page fails because the connection string is not set yet when the grid needs it during its own initialization step. The GridView control, as well as other new data-bound controls such as DetailsView and FormView, start their binding process as soon as the DataSourceID property is set. In the preceding code, the DataSourceID property is set declaratively meaning that the binding process is started at initialization time. The grid receives its data from the SqlDataSource1; but this control has not yet been fully initialized and its connection string property is not set at this time. (No data-binding event has been triggered yet.) Hence, the runtime error.
In ASP.NET 2.0, dynamic $-expressions serve the purpose of setting control properties declaratively without relying on the data binding mechanism and without incurring in the unfortunate situation described above. A $-expression is evaluated in place and during the initialization of the control care of the internal method that builds the control from the source ASPX markup. Here's how to rewrite the preceding code to make it work with $-expressions:
<asp:GridView id="grid" runat="server" datasourceid="SqlDataSource1" /> <asp:SqlDataSource id="SqlDataSource1" runat="server" ConnectionString=<% $ConnectionStrings:[...] %> : />
To declaratively bind a control property to the value of the expression you follow the schema below:
<%$ Prefix:Expression %>
The prefix refers to the type of the expressions whereas the expression is the body of the expression. ASP.NET 2.0 supports three types of expressions: ConnectionStrings, AppSettings, and Resources. They respectively retrieve data from the <connectionStrings> and <appSettings> section of the web.config file and from the application resources. The expression contains detailed information to locate the piece of data to retrieve. For example, for connection strings, it points to the name of the entry in the section where the physical connection string is stored.
