----- Original Message ----- From: "Joe Germuska" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Monday, September 29, 2003 9:37 AM Subject: Re: Reviving PageController (ViewController?) discussion?
> 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. I understand that. In the past, there were many things that people thought very *important*. But after a while, the things could become not that *important* or totally irrelevant. So sometime, born-to-be-deprecated classes could be invented. That's the thing I would like to avoid. People could produce something in Struts 1.x that is still in line with Struts 2.x. > 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? The application here refers to a web application as defined by the Java Servlet Specification which corresponds to a ServletContext. The module here refers to the resources covered by a ModuleConfig as defined in Struts. When you set up things in a ServletContext, they are application-wide settings. When you set up things in a ModuleConfig, they are considered as module-wide settings. The important things for ModuleConfig is that better organized solutions should be packaged in modules so that different packaged solutions could work peacefully in one web application. > > >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? No. Module-wide settings could serve both presentation components and business logic components. > >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. That could be possible. But in the meanwhile, we do not want Struts 2 to be reduced into a-few-line framework. Some heavy duty work has to be done somewhere. > 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. Yes. You could switch the module settings in a Command by invoking the method in the interface. > > Joe > Jing --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
