>From an earlier discussion (Where is Struts 2 going?), I could see people kind of agree with the following picture.
We have two adjacent layers around Struts 2, one above and one below: 1) Presentation Layer: Struts html tags, JSF, Velocity, and many others. 2) Business Logic Layer: Horizontal and/or vertical logic components. Upward, Struts 2 will integrate different presentations and downward it will integrate different business logic components. This is the way I see Struts' future - where its core role is promoted beyond its traditional controller's role. Some people would argue that Struts already *integrated* many of technologies, but as you will see, the real integration framework is not born yet if you realize the challenging problems. How we integrate them and in what ways when we want our end users could use them in ONE web application? This is part of our research areas at http://www.netspread.com and I believe it also belongs to Struts' core interests. The PageController/ViewController touches this area and I would like to share what I learned over the years on this topic with experts here. The design goal of the PC/VC is to prepare the *required* settings for the next view. The intention is fully justified, but we have too many questions as Joe pointed out below. Now I encourage people to think as a businessman. When you are using a set of view components in a web application, you find you need another set of view components from a different vendor, how do you combine them in one web application easily? Is this possible? Yes, if Struts 2 could provide an integratable environment along the concept of modules. Our research shows that every kind of presentation could have two basic settings, application-wide settings and module-wide settings. The Chain takes care of the application-wide settings, the ModuleConfig (and some other interfaces) takes care of the module-wide settings. The vendors package their view components as a set of modules with minimum requirements on application-wide settings for maximum compatibility with other vendors. Here I use the term, vendors, to denote possible commercial vendors and/or open source project teams, like Velocity/Cocoon. The granularity of module-wide settings is also good enough: they could be there for many pages, or one page, or even zero page. What are the examples of module-wide settings? For Struts 1.1, MessageResources, ModuleConfig ( ContentType, Nocache, ...) ActionMapping, etc. When application flow run across module boundaries, the module-wide settings MUST be automatically switched to support possible different vendors' view components. This is what we are missing in Struts 1.1. For JSF, they could be RenderKit, VariableResolver, PropertyResolver, etc. If anyone is interested in seeing how a sample module switch is happening, check it out in the GuideProcessor class. It is very primitive at present stage without any fancy classes or interfaces, but the core idea is there in hope Struts 2 will give us a true integratable environment. If one buys the concepts illustrated above, we name such a class as PageController/ViewController is inappropriate in two aspects: - A well designed framework should not have overlapped concepts, or terms that lead to overlapped concepts. We have the concept of action controllers, we should not have more *controllers* when a view is under preparations. - The class is responsible for switching module-wide settings. A ModuleSwitch(Command) would be closer to what it really does. The method name prepareView() is too narrow because we may also switch module-wide settings for underlying business logic components, for example, the root initial context for the components in a module. The prepareView() should not return ForwardConfig. There should be no custom logic inside as I explained before. There is a technique problem. How do we switch module-wide settings given only the target ForwardConfig? What we are doing is to add a prefix attribute in our HyperActionForward class. Then we could look for the target ModuleConfig according to the prefix. The object only points to the next *logical* page, then the *physical* page is looked up and finally forwarded to. We need both current ForwardConfig and target ForwardConfig and there is an equals() method to compare two ForwardConfig(s). So the thing is not that *simple*. For example, what the future ForwardConfig will look like in order to accommodate a variety of presentation technologies? This is a very *vague* area that should draw many experts from different view/logic technologies to work out a common solution for all. When I was at school, my supervisor always asked me what's the state-of-the-art in your proposals. I think there is a state-of-the-art somewhere, we need to find it. In the end, we should be able to let the users to drop a jar file in WEB-INF/lib and register some settings in web.xml for new modules, and then see it working with no codes or very little custom codes. Anybody who is working in this area, I am willing to provide my help to fine tune concepts, proposals, and potential codes. Jing Netspread Carrier http://www.netspread.com "When we find it, we decouple it. When we use it, we integrate it." ----- Original Message ----- From: "Joe Germuska" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Sunday, September 28, 2003 4:55 PM Subject: Re: Reviving PageController (ViewController?) discussion? > I've been thinking about this a bit; as I see it now, some > implementation choices might be a little contentious, so I feel like > the right approach is discuss first, code later. > > Below is my interpretation of the interface based on earlier > discussion and such. Note that I suggest we change the name from > "PageController" to "ViewController", although I don't feel very > strongly about it. It's just one method (plus some javadoc to flesh > out the idea.) > > package org.apache.struts.action; > > public interface ViewController { > > /** > * <p>Perform any view-level preparations after an [EMAIL PROTECTED] Action} > has executed > * and before the display is rendered. Return a [EMAIL PROTECTED] ForwardConfig} > * instance describing where and how control should be forwarded, or > * <code>null</code> if the response has already been completed.</p> > * > * <p>In the simplest case, where an implementation only modifies the > * request context, the return value may be the same as the > <code>ForwardConfig</code> > * provided as an argument. However, note that implementations should not > * directly modify the given ForwardConfig if it is not the appropriate > * return value; they must instead return a new instance > * (or an implementation-level cached instance).</p> > * > * @param forward The ForwardConfig in whose context this controller is > * being invoked. > * @param request The HTTP request we are processing > * @param response The HTTP response we are creating > * @return a ForwardConfig which will be used for final view dispatch, > * or null if the response has already been completed > * @exception Exception if the view preparation process throws > * an exception > */ > public ForwardConfig prepareView( > ForwardConfig forward, > HttpServletRequest request, > HttpServletResponse response) > throws Exception; > > I think it's important (as noted in the JavaDoc) to help people > understand that they can't change a "frozen" ForwardConfig. (I kind > of feel like this belongs more in something like o.a.s.view, but if > it's going to be the only class there...) > > At 10:31 -0400 9/15/03, Ted Husted wrote: > >I'll post more on this later, but to avoid the "gotcha", I'm now > >thinking we should try this using a modified > >ActionMapping.findForward method. In that way, all the navigational > >control stays within the Action. > > The part that seems like it might raise some discussion is about who > manages the ViewControllers. It seems wasteful to instantiate one > each time a view is dispatched. So then does the base ActionMapping > cache ViewControllers? If that's the case, then what about > Module-level "global forwards"? You could make a simple support > class that wrapped up the instantiation and caching and have it > available to ActionMapping and implementations of ModuleConfig -- and > just to note, the fact that ModuleConfig is an interface leaves open > the risk that existing implementations wouldn't implement the new, > more complex contract of "findForwardConfig". > > I guess I'm waiting to hear more on Ted's teaser; I'm not sure I see > the gotcha that makes hiding this behavior in ActionMapping better > than making it the responsibility of the RequestProcessor, which > seems like a clearer place to put a single cache of ViewController > classes -- which seems to be how Tiles works. > > If people want to weigh in on this, I'll distill the discussion into > draft code once we think the path is clear. > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "We want beef in dessert if we can get it there." > -- Betty Hogan, Director of New Product Development, National > Cattlemen's Beef Association > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
