I have talked extensively about expression builders in the past, and that is because I find them extremely useful, for building no code solutions.
In a nutshell, it is a design-time mechanism for executing a method which receives some parameters and returns something that will be bound to a control’s property. Anyone who has used resources – <%$ Expression:xxx %> -, bound a connection string or an application setting to a data source control – <%$ ConnectionStrings:xxx %> and <%$ AppSettings:xxx %> – on an ASP.NET page has used expression builders. These expression builders are included with ASP.NET, and do useful things, such as returning a connection string or an application setting from the configuration file, or returning a translated resource according to the current browser culture, without the need to code.
One example would be, for example, picking up some value from the current HttpContext and assigning it to some control’s property. Here’s a simple way to achieve it, using DataBinder.Eval to process possibly complex expressions:
As you can see, there are two methods that may be called in order to retrieve a value:
GetCodeExpression: called on compilable pages when the page is first compiled; the returned code is included on the compiled page;
In this example, I have implemented both methods, so that it can be used in various scenarios. On the GetCodeExpression method I simply return a Code DOM expression that calls the static method GetValue on my expression builder. I have a method that tries to convert the returned value into the target property on the declaring control, in case they are of different types.
Expression builders need to be registered on the Web.config file, on the expressionBuilders section:
Finally, here’s how to use this sample expression builder to feed a Label text on a markup file:
This is identical to having the following code:
The syntax is <%$ MyRegisteredPrefix: SomeString %>, where MyRegisteredPrefix is what you want it to be, and what is registered on Web.config, and SomeString is also a randomly-formed string. Note that the expression builders forbid us to using “ in this string, so, what I did was allow ‘ to be used instead, and replace them at runtime.
What remains to be said is regarding editors for allowing integrated expression builder design inside Visual Studio, but since that is strictly not required, I leave it to some other time.
As usual, hope you find this of use. Look for the other expression builders that I wrote, all code is available on the blog.