I talked about a similar thing here a week or so ago in "Are Web Controls an Anti-Pattern?" post. I will try and take a different angle here to avoid repetition.

I have a deep philosophical problem with two (well more then two but these will do for a start) aspects of web application development:

1. Using code and markup in the same file,
2. Placing or rendering markup in compiled code.

The reasons are discussed in my previous post but I am always happy to repeat them Wink...

I only did a quick skim of the post you referenced (14 pages!! someone should write the book) so I don't know how deep the discussion got into front-controllers and MVC. To me this is a far superior solution compared to the current page controller implementation in ASP.Net. Incidentally one of the Microsoft architecture articles states something like that, as the application complexity increases a front-controller implementation should be considered to replace the existing page-controller one.

Over the last 18 months I have been messing around with Maverick.Net (and my own cut down, very unpolished, version MaverickLite). These frameworks allow very complete and clean seperation of the presentation and content layers as well as avoiding the two previously listed pet hates.

A quick hello world example demonstrates better then any explanation.

The heart is a workflow map which can be stored in a file somewhere, the important part is an entry like:

 <command name="helloWorld*">
   <controller>
    <model>
     <path value="models/helloWorld.xml" />
    </model>
    <view name="success">
     <transform path="views/helloWorld.xsl"/>
    </view>
   </controller>
  </command>

Where the web.config has an entry like:

<httpHandlers> 
 <add verb="*" path="*.aspx" type="MaverickLite.Dispatcher, MaverickLite" />
   </httpHandlers> 


The flow is:

1. Page request for helloWorld.aspx is received (the helloWorld* is a regular expression so helloWorldA.aspx and helloWorldItsANiceDay.aspx would also get serviced by this entry),
2. A controller is instantiated to build a model. In this case there is a null controller and the model is a simple XML file,
3. The controller instantiates the appropriate view and passes it the model,
4. The view transforms the model and sends the result to the HTTP response stream.

In my view the elegance of the solution is summed up by these features:
1. The content (aka the model), or XML file(s), are produced by OO programmers,
2. The designers produce the transforms (aka the view), or XSL file(s),
3. Steps 1 and 2 can occur in parallel as soon as the XML schema is defined,
4. There is NO script involved,
5. There is NO HTML hard coded or rendered in compiled code.

Despite the fact that I believe the front-controller & MVC approach are far superior to the page-controller one I intially found that it was taking me longer to get the applications up and running. I put this down to familiarity. At the start of the year, after working with the framework for 12 months or so, I did a test on how long it would take to build the IBuySpy site using Maverick.Net (implementation, workflow), it took 20 hours. I suspect this is not much different to the time it would take doing it using a traditional ASP.Net approach? However the big difference would be the maintenance. In the Maverick case all presentation can now safely be handed of to designers!

Regards,

aza