Original Branch
2 views
Skip to first unread message
David Laribee
Jan 6, 2008, 1:55:56 PM1/6/08
to xe...@googlegroups.com
I was thinking about the front controller idea and how it's a bit disingenuous from the approach we've taken internally in Xclaim.
We're basically only using the whole controller/layout/command apparatus to wrap views (user controls) in windows (forms). We started down this path thinking it would be a good idea but it turned out to be fairly heavy handed so we cut our minimal losses and went with a pattern we call "Composite Controller" (which I plan to document on my blog by next week). Ultimately, what we have found, is that the Layout concept is kind of overkill. You are better off creating a Composite Controller where the view is a form and letting that controller either deal with specific role interfaces or a registry of role interfaces to handle widget-style triads that model their views as user controls.
This change will have the benefit of simplifying the Presenter<TView> base class significantly. We have a notion of Start() and Finish() and i think by creating a IWindowView or IFormView we can handle the displaying forms/windows rather cleanly w/in the "startable" semantic defined. There are a number of methods in Presenter that will go away and the notion of "Context" can probably completely disappear (though the jury is out).
I would propose that we lose the [Parameter] attribute that can be applied to Presenter properties. This was there to provide a means of supplying startup data to a presenter in a loosely coupled fashion. I think we should change the Start method to take an IRequest that could have a dictionary of data in it. Then, when you want to make a new presenter, you simply write some specifications that check the data is sufficient/correct. We can run new requests through a "linker" or "routing" service of some sort that could canonicalize key names, make necessary transformations to get loose coupling if that should become desirable.
Given this, I think we should pull back on the front controller idea. While interesting, I think we can capture the merits of a front controller for a smart client by creating a couple of elements:
1. Creating some kind of navigation service that allows links to be fired with request data from views, finding the appropriate presenter and handling the creating of a form / fixing the title / marshaling data into the presenter (startup parameter stuff) / etc.
2. Creating some kind of map.routes analog to intercept the events from #1 above.
One of the main goals of the xeva framework is to keep things really simple and lightweight and provide a nice testing story for a full-stack smart client application. I think the product will be served by removing Controller/Command/Layout and harvesting these ideas in as needed.
I plan on taking out the controller/command/layout stuff that's in there now.
In the meantime I've created a branch where the old stuff can still be seen:
https://xeva.googlecode.com/svn/branches/original
/ Dave
http://thebeelog.com
We're basically only using the whole controller/layout/command apparatus to wrap views (user controls) in windows (forms). We started down this path thinking it would be a good idea but it turned out to be fairly heavy handed so we cut our minimal losses and went with a pattern we call "Composite Controller" (which I plan to document on my blog by next week). Ultimately, what we have found, is that the Layout concept is kind of overkill. You are better off creating a Composite Controller where the view is a form and letting that controller either deal with specific role interfaces or a registry of role interfaces to handle widget-style triads that model their views as user controls.
This change will have the benefit of simplifying the Presenter<TView> base class significantly. We have a notion of Start() and Finish() and i think by creating a IWindowView or IFormView we can handle the displaying forms/windows rather cleanly w/in the "startable" semantic defined. There are a number of methods in Presenter that will go away and the notion of "Context" can probably completely disappear (though the jury is out).
I would propose that we lose the [Parameter] attribute that can be applied to Presenter properties. This was there to provide a means of supplying startup data to a presenter in a loosely coupled fashion. I think we should change the Start method to take an IRequest that could have a dictionary of data in it. Then, when you want to make a new presenter, you simply write some specifications that check the data is sufficient/correct. We can run new requests through a "linker" or "routing" service of some sort that could canonicalize key names, make necessary transformations to get loose coupling if that should become desirable.
Given this, I think we should pull back on the front controller idea. While interesting, I think we can capture the merits of a front controller for a smart client by creating a couple of elements:
1. Creating some kind of navigation service that allows links to be fired with request data from views, finding the appropriate presenter and handling the creating of a form / fixing the title / marshaling data into the presenter (startup parameter stuff) / etc.
2. Creating some kind of map.routes analog to intercept the events from #1 above.
One of the main goals of the xeva framework is to keep things really simple and lightweight and provide a nice testing story for a full-stack smart client application. I think the product will be served by removing Controller/Command/Layout and harvesting these ideas in as needed.
I plan on taking out the controller/command/layout stuff that's in there now.
In the meantime I've created a branch where the old stuff can still be seen:
https://xeva.googlecode.com/svn/branches/original
/ Dave
http://thebeelog.com
Dave Laribee
Jan 6, 2008, 6:10:14 PM1/6/08
to xeva
Just noticed the link below requires authentication. You'll have
better luck viewing this through a browser:
http://xeva.googlecode.com/svn/branches/original/
On Jan 6, 1:55 pm, "David Laribee" <da...@laribee.com> wrote:
> I was thinking about the front controller idea and how it's a bit
> disingenuous from the approach we've taken internally in Xclaim.
> ...
better luck viewing this through a browser:
http://xeva.googlecode.com/svn/branches/original/
On Jan 6, 1:55 pm, "David Laribee" <da...@laribee.com> wrote:
> I was thinking about the front controller idea and how it's a bit
> disingenuous from the approach we've taken internally in Xclaim.
Reply all
Reply to author
Forward
0 new messages