You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2003/09/28 23:55:29 UTC
Re: Reviving PageController (ViewController?) discussion?
I've been thinking about this a bit; as I see it now, some
implementation choices might be a little contentious, so I feel like
the right approach is discuss first, code later.
Below is my interpretation of the interface based on earlier
discussion and such. Note that I suggest we change the name from
"PageController" to "ViewController", although I don't feel very
strongly about it. It's just one method (plus some javadoc to flesh
out the idea.)
package org.apache.struts.action;
public interface ViewController {
/**
* <p>Perform any view-level preparations after an {@link Action}
has executed
* and before the display is rendered. Return a {@link ForwardConfig}
* instance describing where and how control should be forwarded, or
* <code>null</code> if the response has already been completed.</p>
*
* <p>In the simplest case, where an implementation only modifies the
* request context, the return value may be the same as the
<code>ForwardConfig</code>
* provided as an argument. However, note that implementations should not
* directly modify the given ForwardConfig if it is not the appropriate
* return value; they must instead return a new instance
* (or an implementation-level cached instance).</p>
*
* @param forward The ForwardConfig in whose context this controller is
* being invoked.
* @param request The HTTP request we are processing
* @param response The HTTP response we are creating
* @return a ForwardConfig which will be used for final view dispatch,
* or null if the response has already been completed
* @exception Exception if the view preparation process throws
* an exception
*/
public ForwardConfig prepareView(
ForwardConfig forward,
HttpServletRequest request,
HttpServletResponse response)
throws Exception;
I think it's important (as noted in the JavaDoc) to help people
understand that they can't change a "frozen" ForwardConfig. (I kind
of feel like this belongs more in something like o.a.s.view, but if
it's going to be the only class there...)
At 10:31 -0400 9/15/03, Ted Husted wrote:
>I'll post more on this later, but to avoid the "gotcha", I'm now
>thinking we should try this using a modified
>ActionMapping.findForward method. In that way, all the navigational
>control stays within the Action.
The part that seems like it might raise some discussion is about who
manages the ViewControllers. It seems wasteful to instantiate one
each time a view is dispatched. So then does the base ActionMapping
cache ViewControllers? If that's the case, then what about
Module-level "global forwards"? You could make a simple support
class that wrapped up the instantiation and caching and have it
available to ActionMapping and implementations of ModuleConfig -- and
just to note, the fact that ModuleConfig is an interface leaves open
the risk that existing implementations wouldn't implement the new,
more complex contract of "findForwardConfig".
I guess I'm waiting to hear more on Ted's teaser; I'm not sure I see
the gotcha that makes hiding this behavior in ActionMapping better
than making it the responsibility of the RequestProcessor, which
seems like a clearer place to put a single cache of ViewController
classes -- which seems to be how Tiles works.
If people want to weigh in on this, I'll distill the discussion into
draft code once we think the path is clear.
Joe
--
Joe Germuska
Joe@Germuska.com
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Reviving PageController (ViewController?) discussion?
Posted by Gary VanMatre <va...@wyantdata.com>.
I've been following this thread and solicited you opinions individually.
I thought I might throw out some ideas.
We have developed a struts plug-in that we called rustts (see
attachment). It has properties of a page controller and view
controller.
We implemented the page controller as a subclass of the DispatchAction
class. It combines principles of the DispatchAction and
LookupDispatchAction. This controller handles the creation of various
types of model classes that are associated with visual components thru
our struts extension XML file.
The visual components are defined through xml entries which support
metadata inheritance, much like tiles. Each visual component can be
associated with a model class that controls visual aspects such as if
the visual element should be displayed. The composition of visual
components on a page is defined in the extension XML file. The page XML
element, being the outermost visual element, is associated with the
struts action using a custom attribute in a subclass of ActionMapping.
We have created view helpers that we use within JSP fragments that are
pulled together using tiles. These view helpers use the metadata and
the associated modules to render the view. Currently the helpers make
heavy use of scriptlet. Eventually we could build custom tags that use
the helpers to render the page but we like the ability to quickly change
the skin of a visual element. For example we have a vertical menu and
horizontal menu that use the same helper to render a different
presentation. These view helpers could also be used by velocity to
render a presentation.
We have extended the ActionMapping and ActionForward classes to simplify
propagation of properties in the form bean to the target page.
<action path="/docInfoCategoryEdit" name="DocInfoCategoryForm"
validate="true" input=".dynaPage" scope="request"
parameter="cmd"
type="com.rustts.action.RusttsDispatchAction"
className="com.rustts.action.RusttsActionMapping">
<set-property property="pageId"
value="docInfoCategoryEditPage"/>
<forward name="quit" path="/Welcome.do" redirect="true"
className="com.rustts.action.RusttsForwardAction">
<set-property property="arg6" value="dcDivision" />
</forward>
<!-- next button -->
<forward name="save-success" path="/docInfoType.do"
redirect="false"
className="com.rustts.action.RusttsForwardAction">
<set-property property="arg1" value="drId" />
<set-property property="arg2" value="dcCode" />
<set-property property="arg3" value="drName" />
<set-property property="arg4" value="drComment" />
<set-property property="arg5" value="drOrigIndic" />
<set-property property="arg6" value="dcDivision" />
</forward>
<!-- validate button -->
<forward name="add-success" path="/docInfoCategoryValidate.do"
redirect="false"
className="com.rustts.action.RusttsForwardAction">
<set-property property="arg1" value="drId" />
<set-property property="arg6" value="dcDivision" />
</forward>
</action>
Each model has a public interface that provides callback methods that
can be implemented to conditionally effect different aspects about a
page or how a visual component behaves within a page.
We have extended the TilesRequestProcessor to cache the metadata loaded
by our plugin in request scope making it available to other resources.
Our extension sits on top of struts and is really where we came up with
the name "rustts". Besides being an anagram of Struts, our vision was
that rust�is�a natural byproduct of metal structures of impressive
stature,�and that often rust is most visible where the struts are
joined.
Regards,
Gary
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Sunday, September 28, 2003 8:13 PM
To: Struts Developers List
Subject: Re: Reviving PageController (ViewController?) discussion?
Here's a third idea:
Instead of creating a new class, we could just associate an Action class
with the ActionForward. This is what people do now anyway. It seems to
work, but wastes an ActionMapping and trip through the container.
So, we just add a "type" property to ActionForward, and a step to the
RequestProcessor to handle it when available. If it's there, it gets
called, and the RequestProcess forward to the path. If it's not there,
the RP forwards to the path given by the original forward. Everything
else remains the same.
I'm sure some people will misuse the feature, but some people will
always misuse any feature. At least this way, we recognize what most
people (including me) already do most of the time, put an Action in
front of page. The advantage being that we don't have to waste an
ActionMapping or a trip through the container just to forward to the
page.
-Ted.
Joe Germuska wrote:
> I've been thinking about this a bit; as I see it now, some
> implementation choices might be a little contentious, so I feel like
the
> right approach is discuss first, code later.
>
> Below is my interpretation of the interface based on earlier
discussion
> and such. Note that I suggest we change the name from
"PageController"
> to "ViewController", although I don't feel very strongly about it.
It's
> just one method (plus some javadoc to flesh out the idea.)
>
> package org.apache.struts.action;
>
> public interface ViewController {
>
> /**
> * <p>Perform any view-level preparations after an {@link Action}
> has executed
> * and before the display is rendered. Return a {@link
ForwardConfig}
> * instance describing where and how control should be forwarded,
or
> * <code>null</code> if the response has already been
completed.</p>
> *
> * <p>In the simplest case, where an implementation only modifies
the
> * request context, the return value may be the same as the
> <code>ForwardConfig</code>
> * provided as an argument. However, note that implementations
> should not
> * directly modify the given ForwardConfig if it is not the
appropriate
> * return value; they must instead return a new instance
> * (or an implementation-level cached instance).</p>
> *
> * @param forward The ForwardConfig in whose context this
controller is
> * being invoked.
> * @param request The HTTP request we are processing
> * @param response The HTTP response we are creating
> * @return a ForwardConfig which will be used for final view
dispatch,
> * or null if the response has already been completed
> * @exception Exception if the view preparation process throws
> * an exception
> */
> public ForwardConfig prepareView(
> ForwardConfig forward,
> HttpServletRequest request,
> HttpServletResponse response)
> throws Exception;
>
> I think it's important (as noted in the JavaDoc) to help people
> understand that they can't change a "frozen" ForwardConfig. (I kind
of
> feel like this belongs more in something like o.a.s.view, but if it's
> going to be the only class there...)
>
> At 10:31 -0400 9/15/03, Ted Husted wrote:
>
>> I'll post more on this later, but to avoid the "gotcha", I'm now
>> thinking we should try this using a modified
ActionMapping.findForward
>> method. In that way, all the navigational control stays within the
>> Action.
>
>
> The part that seems like it might raise some discussion is about who
> manages the ViewControllers. It seems wasteful to instantiate one
each
> time a view is dispatched. So then does the base ActionMapping cache
> ViewControllers? If that's the case, then what about Module-level
> "global forwards"? You could make a simple support class that wrapped
> up the instantiation and caching and have it available to
ActionMapping
> and implementations of ModuleConfig -- and just to note, the fact that
> ModuleConfig is an interface leaves open the risk that existing
> implementations wouldn't implement the new, more complex contract of
> "findForwardConfig".
>
> I guess I'm waiting to hear more on Ted's teaser; I'm not sure I see
the
> gotcha that makes hiding this behavior in ActionMapping better than
> making it the responsibility of the RequestProcessor, which seems like
a
> clearer place to put a single cache of ViewController classes -- which
> seems to be how Tiles works.
>
> If people want to weigh in on this, I'll distill the discussion into
> draft code once we think the path is clear.
>
> Joe
>
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design -
<http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Reviving PageController (ViewController?) discussion?
Posted by Ted Husted <hu...@apache.org>.
Here's a third idea:
Instead of creating a new class, we could just associate an Action class
with the ActionForward. This is what people do now anyway. It seems to
work, but wastes an ActionMapping and trip through the container.
So, we just add a "type" property to ActionForward, and a step to the
RequestProcessor to handle it when available. If it's there, it gets
called, and the RequestProcess forward to the path. If it's not there,
the RP forwards to the path given by the original forward. Everything
else remains the same.
I'm sure some people will misuse the feature, but some people will
always misuse any feature. At least this way, we recognize what most
people (including me) already do most of the time, put an Action in
front of page. The advantage being that we don't have to waste an
ActionMapping or a trip through the container just to forward to the page.
-Ted.
Joe Germuska wrote:
> I've been thinking about this a bit; as I see it now, some
> implementation choices might be a little contentious, so I feel like the
> right approach is discuss first, code later.
>
> Below is my interpretation of the interface based on earlier discussion
> and such. Note that I suggest we change the name from "PageController"
> to "ViewController", although I don't feel very strongly about it. It's
> just one method (plus some javadoc to flesh out the idea.)
>
> package org.apache.struts.action;
>
> public interface ViewController {
>
> /**
> * <p>Perform any view-level preparations after an {@link Action}
> has executed
> * and before the display is rendered. Return a {@link ForwardConfig}
> * instance describing where and how control should be forwarded, or
> * <code>null</code> if the response has already been completed.</p>
> *
> * <p>In the simplest case, where an implementation only modifies the
> * request context, the return value may be the same as the
> <code>ForwardConfig</code>
> * provided as an argument. However, note that implementations
> should not
> * directly modify the given ForwardConfig if it is not the appropriate
> * return value; they must instead return a new instance
> * (or an implementation-level cached instance).</p>
> *
> * @param forward The ForwardConfig in whose context this controller is
> * being invoked.
> * @param request The HTTP request we are processing
> * @param response The HTTP response we are creating
> * @return a ForwardConfig which will be used for final view dispatch,
> * or null if the response has already been completed
> * @exception Exception if the view preparation process throws
> * an exception
> */
> public ForwardConfig prepareView(
> ForwardConfig forward,
> HttpServletRequest request,
> HttpServletResponse response)
> throws Exception;
>
> I think it's important (as noted in the JavaDoc) to help people
> understand that they can't change a "frozen" ForwardConfig. (I kind of
> feel like this belongs more in something like o.a.s.view, but if it's
> going to be the only class there...)
>
> At 10:31 -0400 9/15/03, Ted Husted wrote:
>
>> I'll post more on this later, but to avoid the "gotcha", I'm now
>> thinking we should try this using a modified ActionMapping.findForward
>> method. In that way, all the navigational control stays within the
>> Action.
>
>
> The part that seems like it might raise some discussion is about who
> manages the ViewControllers. It seems wasteful to instantiate one each
> time a view is dispatched. So then does the base ActionMapping cache
> ViewControllers? If that's the case, then what about Module-level
> "global forwards"? You could make a simple support class that wrapped
> up the instantiation and caching and have it available to ActionMapping
> and implementations of ModuleConfig -- and just to note, the fact that
> ModuleConfig is an interface leaves open the risk that existing
> implementations wouldn't implement the new, more complex contract of
> "findForwardConfig".
>
> I guess I'm waiting to hear more on Ted's teaser; I'm not sure I see the
> gotcha that makes hiding this behavior in ActionMapping better than
> making it the responsibility of the RequestProcessor, which seems like a
> clearer place to put a single cache of ViewController classes -- which
> seems to be how Tiles works.
>
> If people want to weigh in on this, I'll distill the discussion into
> draft code once we think the path is clear.
>
> Joe
>
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Reviving PageController (ViewController?) discussion?
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Reviving PageController (ViewController?) discussion?
Posted by Ted Husted <hu...@apache.org>.
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.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Reviving PageController (ViewController?) discussion?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:28 -0400 9/30/03, Ted Husted wrote:
>Joe Germuska wrote:
>>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.
>
>Personally, I like returning the ForwardConfig instead of a String
>since it's extensible. You can always call a method to get whichever
>String you want, the logical name or the system path.
Well, the string would just look up a ForwardConfig or ViewController
one level out, and I figured you'd still have extensibility and
configurability there.
My thinking (admittedly still in progress even now) is that I don't
really love the implementation of "processForwardConfig" because it
seems to focus on a limited area of how views are rendered.
Shouldn't the responsibility for seeing that a response is rendered
be encapsulated in the ForwardConfig or a a more active class like
ViewController, instead of having the RequestProcessor assume that
forwarding is the way to dispatch to a view?
I'll acknowledge that this is fairly theoretical, and practically
speaking, probably 99% of actions prefer to use
RequestDispatcher.forward to pass off to the view. And arguably even
when we now write to the response output stream and return a null
ForwardConfig, that might be best implemented in another Servlet in
the WebApp, to keep Struts more a pure Controller.
One small itch about just going ahead and using Action as a
ViewController -- should the framework make a more explicit mechanism
for communication between the controller action and the view action?
Certainly, they can just agree to use "well-known" request
attributes, but is that good enough?
>But once you take these two related cases together, I do believe an
>Action extension point for the ForwardConfig would be useful and
>justified. We've been taking about making the forward smarter for
>years. Now that we have a more flexible request processor, perhaps
>it's time to make it smarter in the usual way, by giving it an
>Action class.
OK... so let's go along this line. What ActionMapping gets passed
to the view Action? The same that was passed to the control Action?
What if I want per-forward configuration details in the
struts-config.xml? Do we need to extend ForwardConfig to have all
the same configuration properties that ActionConfig has? There are
some overlaps, so that could be tricky.
I do like the possibility that the ActionForm passed in to the view
action could be the one which will be presented on the view page,
instead of the one which was populated from request parameters --
this solves the very common problem of people needing to pre-fill a
form.
There's still the question of who instantiates and manages the view
action instances; I guess it would be ActionMapping?
Joe
--
Joe Germuska
Joe@Germuska.com
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Reviving PageController (ViewController?) discussion?
Posted by Ted Husted <hu...@apache.org>.
Joe Germuska wrote:
> 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.
Personally, I like returning the ForwardConfig instead of a String since
it's extensible. You can always call a method to get whichever String
you want, the logical name or the system path.
In terms of what a framework based on Commons Chain might be like, I've
made some notes here:
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/WHITEBOARD.html
But the cool thing about Chain is that it plays well with others. You
can start using a Chain solution in your Actions at any time. The Action
path could be a command name keyed to the business logic. Likewise, the
ActionForward name could be another command keyed to the presentation
side of the business logic. (What raw materials will be needed by the
controls client specified for the target page.)
But, there's also another aspect to the view controller use case --
better support for i18n. The message bundles are a great start, but many
applications need to branch to different paths for different locales, or
even different clients. So, aside from preparing the request, we could
also use a View Action to munge the path (in a new instance of
ForwardConfig). Of course, the nuts-and-bolts of this process could be
encapsulated in a Chain.
But once you take these two related cases together, I do believe an
Action extension point for the ForwardConfig would be useful and
justified. We've been taking about making the forward smarter for years.
Now that we have a more flexible request processor, perhaps it's time to
make it smarter in the usual way, by giving it an Action class.
I agree that you could collapse the "business" Action and the
"presentation" Action into a single Chain. But, as much as I like Chain,
I don't know if I want to present it as the final solution to this
problem. Even with Chain, I might want to separate the concern of
calling the "business" command from the concern of calling the
"presentation" command.
I might even want to put them in different catalogs. One set of Actions
could be calling a standard set of DAO commands. Another might be
calling a set of commands geared for the presentation layer. One might
be in a JAR handed down from another team. The second might be in my
WEB-INF directory. Of course, you could combine these into the same
runtime catalog, but then you have to micro-manage the namespaces and
all that. TANSTAFL.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Reviving PageController (ViewController?) discussion?
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Joe Germuska" <Jo...@Germuska.com>
To: "Struts Developers List" <st...@jakarta.apache.org>
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Reviving PageController (ViewController?) discussion?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 1:24 -0500 9/29/03, Jing Zhou wrote:
>>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
Joe@Germuska.com
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Reviving PageController (ViewController?) discussion?
Posted by Jing Zhou <ji...@netspread.com>.
>From an earlier discussion (Where is Struts 2 going?), I could see
people kind of agree with the following picture.
We have two adjacent layers around Struts 2, one above and
one below:
1) Presentation Layer:
Struts html tags, JSF, Velocity, and many others.
2) Business Logic Layer:
Horizontal and/or vertical logic components.
Upward, Struts 2 will integrate different presentations and
downward it will integrate different business logic components.
This is the way I see Struts' future - where its core role is
promoted beyond its traditional controller's role.
Some people would argue that Struts already *integrated*
many of technologies, but as you will see, the real integration
framework is not born yet if you realize the challenging
problems.
How we integrate them and in what ways when we want
our end users could use them in ONE web application?
This is part of our research areas at http://www.netspread.com
and I believe it also belongs to Struts' core interests.
The PageController/ViewController touches this area and I
would like to share what I learned over the years on this
topic with experts here.
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.
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.
Here I use the term, vendors, to denote possible
commercial vendors and/or open source project teams,
like Velocity/Cocoon. The granularity of module-wide
settings is also good enough: they could be there for many
pages, or one page, or even zero page.
What are the examples of module-wide settings?
For Struts 1.1, MessageResources, ModuleConfig (
ContentType, Nocache, ...) ActionMapping, etc.
When application flow run across module boundaries,
the module-wide settings MUST be automatically switched
to support possible different vendors' view components.
This is what we are missing in Struts 1.1.
For JSF, they could be RenderKit, VariableResolver,
PropertyResolver, etc. If anyone is interested in seeing how
a sample module switch is happening, check it out in the
GuideProcessor class. It is very primitive at present stage
without any fancy classes or interfaces, but the core idea is
there in hope Struts 2 will give us a true integratable environment.
If one buys the concepts illustrated above, we name such
a class as PageController/ViewController is inappropriate in
two aspects:
- 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.
- The class is responsible for switching module-wide
settings. A ModuleSwitch(Command) would be
closer to what it really does.
The method name prepareView() is too narrow because
we may also switch module-wide settings for underlying
business logic components, for example, the root initial
context for the components in a module.
The prepareView() should not return ForwardConfig.
There should be no custom logic inside as I explained
before.
There is a technique problem. How do we switch
module-wide settings given only the target
ForwardConfig?
What we are doing is to add a prefix attribute in our
HyperActionForward class. Then we could look for
the target ModuleConfig according to the prefix. The
object only points to the next *logical* page, then the
*physical* page is looked up and finally forwarded to.
We need both current ForwardConfig and target
ForwardConfig and there is an equals() method to
compare two ForwardConfig(s).
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?
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.
Anybody who is working in this area, I am willing to
provide my help to fine tune concepts, proposals,
and potential codes.
Jing
Netspread Carrier
http://www.netspread.com
"When we find it, we decouple it.
When we use it, we integrate it."
----- Original Message -----
From: "Joe Germuska" <Jo...@Germuska.com>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Sunday, September 28, 2003 4:55 PM
Subject: Re: Reviving PageController (ViewController?) discussion?
> I've been thinking about this a bit; as I see it now, some
> implementation choices might be a little contentious, so I feel like
> the right approach is discuss first, code later.
>
> Below is my interpretation of the interface based on earlier
> discussion and such. Note that I suggest we change the name from
> "PageController" to "ViewController", although I don't feel very
> strongly about it. It's just one method (plus some javadoc to flesh
> out the idea.)
>
> package org.apache.struts.action;
>
> public interface ViewController {
>
> /**
> * <p>Perform any view-level preparations after an {@link Action}
> has executed
> * and before the display is rendered. Return a {@link
ForwardConfig}
> * instance describing where and how control should be forwarded, or
> * <code>null</code> if the response has already been completed.</p>
> *
> * <p>In the simplest case, where an implementation only modifies the
> * request context, the return value may be the same as the
> <code>ForwardConfig</code>
> * provided as an argument. However, note that implementations
should not
> * directly modify the given ForwardConfig if it is not the
appropriate
> * return value; they must instead return a new instance
> * (or an implementation-level cached instance).</p>
> *
> * @param forward The ForwardConfig in whose context this controller
is
> * being invoked.
> * @param request The HTTP request we are processing
> * @param response The HTTP response we are creating
> * @return a ForwardConfig which will be used for final view
dispatch,
> * or null if the response has already been completed
> * @exception Exception if the view preparation process throws
> * an exception
> */
> public ForwardConfig prepareView(
> ForwardConfig forward,
> HttpServletRequest request,
> HttpServletResponse response)
> throws Exception;
>
> I think it's important (as noted in the JavaDoc) to help people
> understand that they can't change a "frozen" ForwardConfig. (I kind
> of feel like this belongs more in something like o.a.s.view, but if
> it's going to be the only class there...)
>
> At 10:31 -0400 9/15/03, Ted Husted wrote:
> >I'll post more on this later, but to avoid the "gotcha", I'm now
> >thinking we should try this using a modified
> >ActionMapping.findForward method. In that way, all the navigational
> >control stays within the Action.
>
> The part that seems like it might raise some discussion is about who
> manages the ViewControllers. It seems wasteful to instantiate one
> each time a view is dispatched. So then does the base ActionMapping
> cache ViewControllers? If that's the case, then what about
> Module-level "global forwards"? You could make a simple support
> class that wrapped up the instantiation and caching and have it
> available to ActionMapping and implementations of ModuleConfig -- and
> just to note, the fact that ModuleConfig is an interface leaves open
> the risk that existing implementations wouldn't implement the new,
> more complex contract of "findForwardConfig".
>
> I guess I'm waiting to hear more on Ted's teaser; I'm not sure I see
> the gotcha that makes hiding this behavior in ActionMapping better
> than making it the responsibility of the RequestProcessor, which
> seems like a clearer place to put a single cache of ViewController
> classes -- which seems to be how Tiles works.
>
> If people want to weigh in on this, I'll distill the discussion into
> draft code once we think the path is clear.
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> 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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org