- 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.
IMHO, a well-designed framework should provide extension points where developers need extensions points. Right now, we have one extension point where a developer can cleanly interject an Action.
In practice, many developers, including myself, have found that they need to interject a second Action to prepare the request for the page. We need two extension points, because there are two decisions being made. The first is "who" will handle the response. The second is "what" material they need to handle it.
I believe we all like the idea of separation of concerns, but most of also do not like splitting responsibilities. Currently, Actions are responsible for doing all the same things we want a page controller to do. So, my current suggestion is to add an extension point to ForwardConfig, so that the RequestProcess can call an Action here as well.
This approach lets developers continue using the Actions we all know and love, but saves the trouble of forwarding the request through container, just to complete the response.
- The class is responsible for switching module-wide settings. A ModuleSwitch(Command) would be closer to what it really does.
IMHO, a large part of the problem is the assumption that "there can only be one" front controller. Many of the module use cases could be solved if multiple instances of the Struts controller were available in an application. One could handle the *.mod1 URIs andother another could handle the *.mod2 URIs. This approach was contrary to the initial Struts architecture, and we decided to pursue the "context-switching" strategy.
For Struts 2, I would suggest starting with the premise that multiple Struts controllers can be available in the application, and that an action can be specified anywhere that a page or forward can be specified now. If the configuration and server pages never need to know what server pattern is being used, since they can refer only to actions, then we can accomplish modules (and I imagine portlets) by registering each player under a different URI pattern.
If we add metadata inheritence, multiple configuration files, and wildcard mappings to the mix, I believe teams would be able to define and use both hierarchical modules or switched modules in the same application.
One element of the front controller pattern is consistency in how incoming requests are handled, which helped to justify the "there can only be one" strategy. Happily, the excellent work that's been done on the RequestProcessor now makes it possible for multiple controllers to share the same customized class. So, we could have our cake and eat it too :)
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.
To an extent, we already have this functionality. A user can drop a WAR file into a container's directory, and presto-bango, they have a web application.
The portlet spec tries to do the same sort of thing one layer down, so that you can drop a PAR file in an application with the sort of result you describe.
The state-of-the-art in for portlets is our own Jetspeed project here at Jarkara (which in fact bred the proposed portlet specification).
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
