----- 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]
