----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, September 30, 2003 6:29 AM Subject: Re: Reviving PageController (ViewController?) discussion?
> Jing Zhou wrote: > > - 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. Well, since the context switch is an interface, it is an extension point by itself. What I am against here is that the context switch could return a different target ForwardConfig (or changing its logical destination page). Determining a target ForwardConfig is the core business of Action(s) before we reach the phase of preparing the view requirements for the next page. It is not a good idea to overlap the Action semantics in the context switch semantics in regard to returning a different ForwardConfig. That is the reason I think we should not have more *controllers*. Note that multiple Actions (or Commands) could be allowed before the phase of preparing the view requirements. > > > > - 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. > I am not aware of the design details in your projects, but I fully agree with the "context-switching" strategy. If you and any developers could advise me about our plan to implement the strategy, that would be great. Here is the pseudo definition: Definition of ModuleSwitch (for the context switch interface): 1) Responsibility: Prepare the context required by the underlying business logic components for the incoming http request and the context required by the presentation components for the outgoing http response (typically a JSP page or template engine). 2) Relationship to ModuleConfig: An instance of ModuleSwitch interface has a one to one correspondence to an instance of ModuleConfig. ModuleConfig provides immutable properties while ModuleSwitch provides mutable properties for wider applicability. 3) Relationship to Chain: There are two points in a request processor Chain that could invoke the methods in ModuleSwitch. - When an incoming http request is received and the current ModuleConfig and ActionMapping is identified, a Command in the Chain should invoke a method in ModuleSwitch to prepare the context required by following Commands that are responsible to execute business logic. - When the final logical target is identified, typically in term of a ForwardConfig returned by previous Action Commands, a Command in the Chain should invoke a method in ModuleSwitch to prepare the context required by presentation components. The implementation of the method could just do in-module switch if the target is in the current module. If the target is in a different module, then out-module switch must be performed. Remark: This is an alpha idea, my gut feeling is that the existence of such interface is fully justified, of course, its name and its method signatures are to be determined and there are a lot of things to be filled. The concept of Logical Target is also introduced. The implementation could translate a logical target to a physical target when it sees fit, much like selecting a Renderer per JSF, or Theme per our project. > > -Ted. > Jing Netspread Carrier http://www.netspread.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]