I totally agree, and I think most advocates of "pull" model design would as well. Note that Turbine (home to the doc that Don referenced) supports and encourages using action classes for actions (requests to "do" something) and pull tools (aka view helpers) for presentation of data (requests to "view" something).
On 10/13/05, Tim Fennell <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
