Here is my solution for the problem explained in the
previous
post.
So the problem was, how can you reuse views (aspx pages) in different
controllers (processes, pageflows, ... whatever you want to call them)?
I'm still using the standard Model-View-Presenter-Controller pattern used by
WCSF but I'm abstracting the controller part from the presenter and I'll be
passing the view (through it's interface) to the controller.
ICanHandleView<TView>
For every view the controller can handle the controller will implement an
interface
ICanHandleView<TView>. This generic interface has
two methods,
HandleView(TView view) and
FillView(TView
view). FillView will be mostly called when the page is loaded to fill
the view with state information and HandleView will be called when an action
occurred (e.g. a button click). In the implementation of HandleView you take
the data from the view, store it in the controller and then decide to which
page you will redirect the user. So basically the Presenter is just there to
translate actions of the UI into calls to the controller.
BasePresenter
When you add a page with WCSF it will also generate a presenter that inherits
from
Presenter<T> where T is the interface of your view.
I've created a class
BasePresenter that inherits from
Presenter<T>.
BasePresenter has a property
Controller that returns a
ICanHandle(TView), behind
the scenes this property uses a static class
ControllerFactory
that creates a new controller or correlates the current request to an existing
controller. So, when WCSF created your presenter you just change the
Presenter<T> it inherits from with
BasePresenter<T>.
ControllerFactory
This little workhorse is responsible to do the correlation between a request
and a new or existing controller. Actually
ControllerFactory is
just a static class that will instantiate the real factory, in my case
WebControllerFactory. This was done to abstract the asp.net
infrastructure from the rest of the system as the
WebControllerFactory will use the
HttpContext to do
the correlation.
I hope I can make this all a bit clearer with the following class
diagram:
(click to enlarge)
Correlation
The correlation strategy of my
WebControllerFactory is the
following:
(click to enlarge)
red dots: flow when the first page of the process is first
requested
green dots: flow when the first page of the process is postbacked
blue dots: flow of all the following pages in the process
The reason I use the hidden field is to avoid that on a postback, of the first
page of the process, a new controller would be created.
Some technical details:
When a controller is redirecting to the next page it should add the "flowid"
parameter to the url. To get to the page object of a request, to add or read
the hidden field value, I use HttpContext.Current.CurrentHandler, this is a
IHttpHandler that can be cassed to a System.Web.UI.Page. To instantiate the
correct controller factory and controllers I used Unity, the details of this I
leave as an exercise to you the reader.
All of this might seem a bit complicated but once this is implemented it's
really easy to use:
- generate your pages and presenters with WCSF
- write the code of your controller, unfortunately you still have to do this
yourself
- configure unity
- change the base class of the presenter to BasePresenter<...>
and it's ready!
If something is not clear or if you would have a better way to do this please
let me know.
