I feel like I should jump in and clear up my position here since the
"Stripes" position is essentially what I wrote in a blog entry ;)
Stripes very happily supports both the push and pull ways of doing
this (and Jason pointed out to me earlier, that WebWork has similar
functionality but I won't speak for their preferences)....
Often times I end up having a page that is read only. The
application I'm developing now is a fairly complex app to facilitate
DNA re-sequencing. We have lots and lots of domain objects, and lots
of search/detail pages. These are the kinds of pages that I think
are perfect candidates for the pull model. They are a very clearly
defined view with a clear responsibility. There's no real decision
making logic, it's all "go pull this data and display it to the
user". By using view helpers, all our search and detail pages are
easy to embed in other pages. I find having pre-actions for this
both awkward and unnecessary. But that doesn't mean that I think
every page should eschew pre-actions in favor of view helpers.
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.
I think (and maybe I'm wrong) that the Struts community tends to use
pre-actions for almost everything. Admittedly Tiles allows you to
use use a pre-action per view fragment, but I'm not sure how many
people make use of that over pre-actions.
I was just trying to point out that my preference is for view helpers
in situations where all you are doing is trying to load a page that
requires some data in order to display, and that I don't think it's
bad to have an application with some direct-to-jsp navigation, and
some through-action navigation.
My 2c.
-t
On Oct 13, 2005, at 1:51 PM, Don Brown 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. In those days, the question was whether to use the push
technique used
by frameworks like Barracuda or pull with powerful JSP tags.
Today, this seems to still be a big issue. Only now, the push
proponents
would be HTML template technologies like Tapestry, Wicket, and Clay.
Technologies like JSF and JSP, even velocity seem to be able to be
used
either way. Looks like Stripes takes the pull position.
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 hope to see this discussion have a resurgence as I think it does
well to
capture two core approaches to web development.
For more reading:
http://jakarta.apache.org/turbine/further-reading/pullmodel.html
Don
On 10/13/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
I came across a discussion about view helpers, started by Tim Fennel,
author of Stripes. He advocates the "inverted" model for displaying
views, when view helper action is called from JSP if needed, instead
of forwarding to JSP page from action, like it works in Struts now.
With his approach, it is possible to navigate directly to JSP. On the
one hand, this is a step backward, since I used to consider a JSP
page
as a mere view, and I prefer to navigate to web resource instead of
navigating to a concrete view.
On the other hand, using JSP directly from browser allows to employ
<jsp:include> without forwarding. Currently I create embedded JSP
controls by including Struts action into a JSP page. The action
forwards to JSP file to render a fragment. Servlet engines do not
like
forwarding, and closes output stream immediately after returning from
forwarded fragment, so the rest of the parent page is not rendered.
Using JSP directly solves the problem, because no forwarding needed.
What about creating a tag that will allow to define a certain bean as
a view helper, and to automatically call something like processView()
on it, and return a string mapping, which could be used to select a
subview. Several subviews can be defined on one JSP page, and be
selected via tag or a scriptlet.
Michael J.
---------------------------------------------------------------------
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]
