(2003 to 2005)

ASP.NET without ASPX files...

Thu Feb 24 08:42:00 UTC+1100 2005


Speaking of using ASP.NET without ASPX files, I've been doing that for some time now.

About three years ago I started a web application, and quickly got overwhelmed trying to use the ASPX model.

It's just too much.

I don't think the 'code-behind' model is a good idea either.

Mind you, I'm not real proud of the solution that I've been using in its stead.

About a year or two ago I created a base class that implemented IHttpHandler with a bunch of template methods, and rendering methods, that would basically define the behaviour of any given web page. I did it one evening because a bloke who was working for me needed to start using it the next day.

The template methods were a great idea.

The rendering methods were a hack.

The system works, and I've got it in production, but it's a maintenance problem, and I have browser compatilbility issues that aren't easily solved, and extensibility issues. It's still way better than ASPX though (particularly from a comprehension/maintenance POV), in my opinion.

Over the past two weeks I've been focusing on the rendering engine for v.Next() of the same reporting tool.

I have a lot of work to do (new database schema, data import, data cleansing, administration utilities, HTML/CSS/JS UI hacking, not to mention all the SQL), and the rendering engine is something that I was hoping to avoid addressing.

But it's unescapably a core component of the entire architecture, and is a prime candidate for reuse in a data-entry aspect of the system (still under development, at least an order of magnitude more complicated) as well as simply in the reporting part that I'm working on now.

So that's what I've been doing for the last couple of weeks, fixing up my ASP.NET rendering engine.

I had a look at nvelocity, but that's not useful for me.

Let me explain how I'm thinking.

Basically a web page is a simple thing.

It is possible to sit down and designate a 'label' or a 'name' for every 'part' of a web page.

It is also possible to arrange those parts into a structure. That is, you will have a Page, a Page will contain a Title, a Page may contain a TopNavigationBar, etc.

Basically you can create a 'document object model'.

Not a HTML document object model mind you.

More of a Web Page document object model.

So that's what I've done (read: am doing).

The big reason for creating a Web Page document object model, is that you can seperate the 'view' from the 'model'.

The ASPX page architecture falls down there, because its 'model' is the 'view'. That is, a System.Web.UI.WebControls.TextBox will render itself. That's bad.

The way my system works is I create the Web Page model and then I designate a renderer.

The Web Page model is specified as a collection of interfaces. I have a 'generic' implementation of those interfaces, and I don't expect I'll need to customise them. My actual HTTP handlers get/create a Web Page Document, configure it with the content they want, nominate a renderer and then render it.

The model can easily render to any flavor of HTML (i.e. 3.2, 4.0, 4.01, X, etc.), to any form of XML schema I wish to support, to PDF, to plain text, to CSV, JPG, GIF, PNG, etc. (The reason for the images is that a component of my Web Page model is a charting engine (or 'charting model' I should say), thus I can give you a 'chart' as a JPG, or GIF, or PNG, or CSV, or XLS, or PDF, etc. because a Chart can be a part of the Content of a Web Page) (I'm drastically oversimplifying there, btw.)

Basically I'm planning to take the generic renderers and make them extensible by derivation. That's how I'll do skin/themes/branding. (Although I still obviously use CSS.)

I'm a big fan of factories, so the entire model can be configured with about two settings in the config file.

I think what I've been doing is a great idea. Unfortunately it's a lot of upfront work.

So far I have about half the model specified and generically implemented. I have a few test HttpHandlers that create the model.

I have two generic renderers, a HTML 4.01 renderer and a PDF renderer.

I'm tired.

I've said enough.

ASPX blows.

Put it this way:

      this.IWebResource.Context.Response.ContentType = this.IWebPage.Renderer.ContentType;
      this.IWebPage.Renderer.Render( this.IWebPage.Document, this.IWebResource.Context.Response.OutputStream );

Copyright © 2003-2005 John Elliot