ASP.NET Expressions — A Useful Feature

Have you looked into ASP.NET expressions yet? Now, that is a very useful feature. If any of you are developing a localizable product and ever needed to output language–specific text with minimum of code, you’ll love this one.

In 1.x “translated” text is returned by a resource manager based on the culture of the executing thread. In 2.0 that’s still the case. However, in 1.x it has always been a royal pain in the butt to actually display language-specic text on a page.

I’ve seen some people create lightweight custom server controls which simply talk to a resource manager class. This allowed them to place these controls on a page with minimum markup. As an alternative, you could create a gazillion of, say, Label controls and assign them text in code-behind. By far the ugliest approach was to try to cram calls to resource managers right from ASPX pages. Yikes!

How about this instead:

<%$ Resources: MyResources, MyText %>

which means, See what the current culture is, find a MyResources file with a corresponding extension (signifying its supported culture), and pull out text with id of MyText. In fact, we, at our company, devised a very similar approach a year ago because we really needed this simplicity. We to tap into a half-documented method of the Page class and use some reflection magic to get this to work, but I’m glad it is baked into the framework itself for once.

These expressions are not limited to language resources only. In a similar fashion, you can display application settings. Here’s an example MSDN offers:

<appSettings>
  <add key="copyright" value="(c)Copyright 2004 Northwind Traders"/>
</appSettings>

With this entry in web config, you can display it the following way:

<%$ AppSettings: copyright %>

You can even plug a connection string straight to a SqlDataSource this way (although I absolutely detest putting data source controls in markup!)

Roll Your Own Expressions

It gets even better: you can roll your own expressions! It’s not that complicated. You need to derive from ExpressionBuilder and override its GetCodeExpression method. Jeff Prosis of the old MFC fame demonstrates how to do this (scroll to Custom Expression Builders). MSDN2 has an example as well.

One thing I haven’t figured out yet is whether I can get to the control tree of the hosting ASP.NET page from my expression builder. If so, it opens up a lot of opportunities to inject tags to be evaluated at run time. If it works, I see expressions put to good use by replacing chunks of page goo that exist only to be customized at run time. It would be a run-time code snippet, if you wish. Who knows—maybe we can build a template language on top of expressions similar to the Tea Template Language (PDF, 300K). Mike Davidson touched on this a while ago.

Pre-Built Expression Builders

Reflector revealed three (public) expression builders shipped with 2.0:

• AppSettingsExpressionBuilder
• ConnectionStringsExpressionBuilder
• ResourceExpressionBuilder

If you visited links to two articles above, these names should be self-explanatory.

I’d like to point out one really odd thing: the AppSettingsExpressionBuilder class has a method, GetAppSetting, which "returns a value from the <appSettings> section of the Web.config file". Isn’t it what AppSettings is for? Reflector shows that there’s not much to it.

Does a call to AppSettingsExpressionBuilder.GetAppSetting (...) look odd to anyone? And what’s up with calling an expression builder to read a configuration setting? Someone forgot to read his copy of the Framework Design Guidelines. :)

The GetAppSetting () method is used as you say to return an app setting, however you may have overlooked who actually calls this.

The idea behind an ExpressionBuilder is that the compiler includes whatever is returned from the GetCodeExpression() method into the assembly that is emitted for the site. GetCodeExpression() returns a CodeMethodInvokeExpression which just so happens to be a call to this static GetAppSetting method.

So, what it's effectively done is generated an inline call to ConfigurationManager.AppSettings["blah"]. Now, Microsoft could have emitted the call directly (without having GetAppSetting in the way), but GetAppSetting also throws an exception if that setting isn't found, whereas AppSettings["blah"] just returns nothing. So it all makes sense, honest!.

It does, Morgan. :)

Just reading about asp.net expressions, you mentioned in the blog above about figuring out if it's possible to access the hosting page from the expressions. Did you find anything about that out (or, is it possible)?

Marcus, nope, I'm afraid I have nothing new to report.