From an earlier discussion (Where is Struts 2 going?), I could see people kind of agree with the following picture.
Thanks for the thorough and thoughtful response/contribution to the discussion. I want to point out that my post is presented in the context of something that is reasonable to do in Struts 1.x, whether or not it is the most ideal design. I'm interested in talking about Struts 2 also, but my proposal is intended more for "fitting-in" than for being ideal.
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.
I'm not sure I understand your distinctions between module and application. As Struts is now, I don't think things break down the way you describe them. Are you talking about Struts 2, or do we just have different models of the responsibilities for the Application and the Module?
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.
OK, so am I to understand that you'd propose that any given Module would be responsible for either "business" or "view" control, but not both? Interesting. I'm not sure I agree yet, but then, one of my original responses after reading your message was to suggest that the View Controller should be implemented as a separate servlet. (In a purely technical sense, that's what JSPs are, and that's how the Velocity integration works too, and my current co-developer was talking about installing a second ActionServlet along these lines earlier in our project...)
I'll have to think about it some more; I am kind of concerned that configuring and coordinating between two Modules (or two Servlets) will be relatively complicated. That may be too much separation-of-concerns. But it's worth thinking about. I think it works with JSPs and Velocity because the domain of those servlets are so well defined.
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?
Looking to Struts 2.x, I am thinking that the ForwardConfig would merge with a ViewController, and that instead of the Struts action returning a ForwardConfig, it would return a logical name (String); then the details (and potential complexities) of dispatching to any chosen view technology, including any view preparation, would be entirely external to the action. Then what I'm calling a merged ForwardConfig/ViewController would actually just be another Command in the processing chain and would actually have a much less defined structure.
Speaking of chains, given Ted's suggestion about just plugging in another Action class as part of the ForwardConfig -- if that were to be the case, I think I'd just be more interested in a Commons-Chain/Struts-Chain solution -- which might be better anyway, as it's more forward looking than any of my suggestions.
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]
