Dynamic Controls Everywhere - Part One: Problem/Initial Solution

One of the tasks I have been given requires me to add a “portal” (for lack of a better term) to our existing intranet website for reporting purposes. The current report section suffers from many problems, the least of which is that it requires a complete application recompile to add a simple link to a new report for our users – terribly inconvenient. The new report section had to be, above all else, configurable (read config files – lots of config files).

A “report” in our application consists of a set of search criteria – e.g. show me sales for business unit A for Q1 of this year (or any year for that matter); the corresponding parameter names required for the report; and a hyper link to a separate web server that generates the report. Most of the aforementioned requirements are hard-coded into the code-behind of the ASP.NET page which makes it difficult to maintain. The current interface lists every possible criterion, as some sort of HTML input control, regardless of the report’s requirement. Once the search options are put into the form fields, the user has to post the page back – we like the client, so let’s try to fix this – which then re-builds all of the report links. Then the user can click on any link and open the corresponding Crystal Report.

Yuck! That’s all I can say. Hard-coding business logic into code-behinds is a big no-no if you ask any software developer. Not only do you have to manage the business logic, but any time a change is needed we have to recompile and redeploy the entire application. This means booting all user sessions and forcing the server to recompile the app into MIL. To resolve part of this problem, I created a configuration file with the following XML arrays that then get loaded into a cached (cache = performance boost when memory is available) custom class.

<criterion>
<criteria type="”“" description="”“" label="”“" assemblyname="”“">parameterName=”“ />
</criterion>
<reports>
<navigationitem description="”“" label="”“" hyperlink="”“">
</reports>

When the Report page is called, the page loads the configuration file (either from the cache or deserializes it using the XmlSerializer) and supplies the custom collections to the Report through Properties – Reports and Criterion (what a coincidence). The page then loops through each collection building the criteria and report links sections of the page with the corresponding collection. Any time we need to add a criteria item or report – we just modify the configuration file and the necessary items just “show up” on the page. Look Ma, no recompilation (twice if you’re keeping count), no redeployment, and we have achieved the maintenance ease.

E-mail me if you would like to see the source code and configuration files.

-Brian