struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <donald.br...@gmail.com>
Subject Re: View helpers a.k.a. "inverted" views
Date Thu, 13 Oct 2005 17:51:09 GMT
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 <jmikus@gmail.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message