Monday, October 30, 2006 6:53 PM
One thing that I would really like to see in MonoRail 2.0 is a better seperation of concerns in regards to the processing pipeline, which should aide extending the MonoRail system. Currently (10/30/2006) the pipeline is modeled in the following classes (This is a simplification, but I think it is helpful none the less.
MonoRailHttpHandlerFactory
MonoRailHttpHandler
Controller.Process()
Controller.InternalSend()
By my evaluation we don't support extension as cleanly as I think it can be done, that said I think we are pretty extensible. What I would like to see is that we have a dedicated model of the MonoRail pipeline that would support and extend the existing ASP.Net pipeline, versus the current model that has a lot of it embedded in the Controller class, which is not where I believe it should be located. Here is my combined pipeline idea.
ASP.Net
- BeginRequest
- AuthenticateRequest (Pre, Post)
- AuthorizeRequest (Pre, Post)
- ResolveRequestCache (Pre, Post)
- PreMapRequestHandler
- PostMapRequestHandler
- AcquireRequestState (Pre, Post)
- PreRequestHandlerExecute
- Page Handler Fired
MonoRail
- SelectController/SelectAction (Pre, Post)
- ExecuteAction (Pre, Post, Around?)
- RenderView (Pre, Post)
- PostRequentHandlerExecute
- ReleaseRequestState
- UpdateRequestCache
- EndRequest
- PreSendRequestHeaders
- PreSendRequestContent
I think something simple like this should be sufficient for a first draft, and once we have extracted the pipeline it souldn't be too hard to add more extension points as neccesary. (I expect the MonoRail experts to chime in here) The first step I want to take is extracting the Action selection logic into a seperate class, this should help extract one of the bigger concerns of the system (this will hopefully remove the need to use SmartDispatcherController, this behavior could instead be modified at config time, with a reasonable default.
One thing I haven't thought much about is how this affects the WizardController. This reminds me that the WizardController has this thing called a WizardActionProvider which is a IDynamicActionProvider. At first blush this seems ok, but we will see.
So what do you think?