Whenever I start a new web project, one of the first things I do is create a "Base" class for all my ASPX code-beside (
"code-behind" is so .NET 1.1) class declarations to inherit from. This makes it easy to have useful properties such as CurrentUser available in all pages automatically. Such a practice is quite common these days, and has been covered in several articles including
this one.
Recently, I have found it useful to have some boolean properties on the base class which control the rendering of certain elements. For example, a current project I'm working on has the requirement to restrict the user's ability to navigate backwards by using the browser's "Back" button. This is accomplished via the use of the
JavaScript "history.forward()" hack. Now, some pages in the application require this while others do not. So the best way to handle this is to have a base-class property called DisableBackButton and set it to "true" when I want to prevent the user from going back to the previous page. And, in fact, this is what I did and it works well.
However, setting such properties can only be achieved with programmatic code. For example, to turn this property "on" for a certain page, I would have to write "DisableBackButton = true;" in the Page_Load event handler. This is fine, but it feels "dirty" and unsophisticated to me. I would much prefer to set this property in a "declarative" fashion on the actual ASPX file rather than writing code to set it. Say, wouldn't it be cool if I could just add an attribute to the @Page directive that said DisableBackButton="True"? Well, it turns out that in ASP.NET 2.0,
you can do exactly this!
Well, almost. If you read all the comments in that link you'll see that it isn't all that simple, unfortunately. First, if you're using a base class like I am, you also have to set the "CodeFileBaseClass" attribute in the @Page directive. Ick. I think this is something that the compiler can determine for itself without me having to tell it explicitly. Requiring me to add it manually just means there's another possible point-of-failure and yet something else that has to be maintained. Still, it's not a too terrible price to pay for the cool declarative property setting feature I'm trying to achieve. But, that isn't the only problem. While the project will now compile, you'll still get ASP.NET validation errors in all your pages saying that "DisableBackButton" is a not a valid attribute for the @Page directive. Grrrr. To stop this message from clogging your Visual Studio errors window, you have to open up Visual Studio's XML-based schema file and
add the attribute. Now this is really a problem since this schema file is used for ALL Visual Studio web projects, not just the one you're working on right now. And it also means that if you share the code with someone else, you have to tell them to go modify their schema file, too. This is completely unacceptable.
In the end I decided to go the old-fashioned route and set this property programmatically in each page that needed it. While the declarative route would have been uber-cool, there are just too many road-bumps down that path. Here's hoping Orcas (or Shamu as my wife calls it) does something to address this problem.