I resolved this in my applications by forwarding to a new action mapping in
stead of directly to the jsp.
My View helper is a plain struts action.
So, in stead of directing to tracelist.jsp after saving users input, I
forward to tracelist.do
<action path="/trace/tracesave"
type="myapp.trace.TraceSaveAction"
name="traceForm"
scope="request"
input="/trace/tracedetail.do">
<forward name="success" path="/trace/tracelist.do"/>
</action>
and
<action path="/trace/tracelist"
type="myapp.trace.TraceListAction"
name="tracelistForm"
scope="session">
<forward name="success" path="/trace/tracelist.jsp"/>
</action>
The advantage of this is that the save action does not have to know what
extra resources are needed for the view page,
and that no new mechanisms are needed to have a View helper in struts.
The disadvantage is that in struts community this is regarded as a bad
practice (action chaining).
My defence to this opinion is that I do not do this to implement business
processess by chaining actions, but that I just need a front controller to
prepopulate resources.
I've opened enhancement request 16107 to support this mechanism.
http://issues.apache.org/bugzilla/show_bug.cgi?id=16107
Jan
-----Original Message-----
From: Michael Jouravlev [mailto:[EMAIL PROTECTED]
Sent: donderdag 13 oktober 2005 21:43
To: Struts Developers List
Subject: Re: View helpers a.k.a. "inverted" views
On 10/13/05, Don Brown <[EMAIL PROTECTED]> wrote:
> This reminds me of the old push vs pull MVC architecture back in
2000/2001.
> The core decision is would you rather _push_ objects into a context in
your
> action class, then let the view use them to generate the page, or, while
> processing your JSP, _pull_ the data into it by calling methods,
processes,
> etc.
...
> Which is better? I don't know if you can determine that for all
situations.
> Push models work better to separate the designer from the developer, and
> generally produce views that are more maintainable. Pull can be easier to
> grasp for the developer and generally minimizes code.
I don't think this is push vs pull. You can navigate to an action,
choose a view and pull needed data into it. Is it push or pull? View
helpers is not about just getting the data, it is about how the
controller/dispathcher is called.
*If* you regard JSP as a *view* technology or in other words, as
data-aware HTML, then the difference is conceptual. In this case
dispatcher (action class + form bean + whatever else) represents a web
resource, possibly stateful, possibly with several views. While JSP
page is, well, just a view.
Therefore navigating to an action and then rendering a view is a
proper (for me, at least) approach, where a user selects a web
resource, and an action renders a view. *User don't select a view, a
web resource does*.
Navigating to JSP page and pulling data into it means navigating to a
concrete view instead of navigating to a resource, which is just plain
wrong if you ask me.
But, if you regard JSP as both *view and controller*, then view
helper/pull model allows to do neat things with <jsp:include>. The
proper [sub]view can be selected by JSP, using scriptlets or tags.
This means offloading part of controller's job to JSP. I don't think
this is a good concept, but it works with currently available servlet
engines, so I might consider using it.
On 10/13/05, Tim Fennell <[EMAIL PROTECTED]> wrote:
> It seems to me anywhere that I'm making complex decisions about which
> view to render, or may have different data to render into the view, a
> pre-action is more appropriate. And I'm always in favor of actions
> to process events from the user when the request is to *do*
> something, not just *view* something.
When you view something, you want to see a resource content, not a
specific view of your choice. You don't know what state the resource
is in, so you cannot assume that view that you navigating to, is valid
or appropriate for current resource's state. This is, if you consider
JSP page *just a view*.
On 10/13/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> is to eliminate the need for tags to wander all over the contexts
> looking for this and that. Instead, it will all be in a single object
> in request scope. (Which in turn might access other objects in session
> or application scope.)
>
> Accessing Struts components directly would be deprecated, and support
> removed in a later release. Access through the ViewContext would be
> cannonical, and tag libs support Struts would need to upgrade.
What about accessing ActionForm properties??? A lot of people do this,
me included. The whole idea of using session-scoped ActionForm in
Struts Dialogs, is that ActionForm keeps state during conversation
with resource. Input goes into actionform automatially
(RequestProcessor.populate), its content may be changed by action, and
then displayed through JSP. Do you want to remove that???? Do I need
to store my stuff somewhere again, and to copy it from form or
whatever input buffer would be, to that context object???
Instead, Action and ActionForm should be combined into one object, which can
be:
* stateful, if needed
* can be accessed from JSP
* can be automatically populated
* contaned lifecycle methods (via interface, like in Shale)
* can respond to input events (like DispatchAction)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
