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. 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.
Agreed. it is still a big question. and yes, velocity does support either. > 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 quite agree. :) I think pull and push are pretty evenly effective maintainability and in separating the developer and the designer. They just do so in different ways. Pull allows developers to give designers a very consistent (and consistently available) interface with much less effort and lower probability of error. This lowers designer requests for X in page Y (more maintenance ability is passed to the designer). Push, on the other hand, limits the designer to just what the developer considers necessary for a page. As parameters change or errors appear, the developer is more responsible and the design aspects are typically simpler. So, yes, your decision should be made situationally, but i wouldn't call it a choice between maintainability and simplicity without specifying whether you're referring to a designer or developer perspective. :) By the way, if i can take this opportunity to do so, VelocityStruts is in need of some upgrades for the Struts 1.2 and/or 1.3 series. I've not been free to use Struts in my paid work and volunteer time has been scarce, so i'm not up to speed on the newer versions. If anyone is interested in helping out, that would much appreciated. :) > 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]
