The View Helper pattern creates presentation *content* which requires processing of dynamic business data. The forces are that the business data assimillation requirements are nontrivial, embedding business logic in the view would promote a copy-and-paste type of reuse, you want a clean separation of labor between the software developers and the web production team, and one view is commonly used to respond to a particular business request.
The solution is to have the view contain only formatting code, delegating its processing responsibilities to helper classes, implemented as Java Beans or custom tags. The helpers also store the view's intermediate data model and serve as business data adapters. In other words, these sorts of solutions have absolutely nothing to do with the View Helper pattern. They are, in fact, antithetical to that pattern. On 5/26/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 5/24/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > Nope, Dave nailed it. Re-read the requirement I described. The point is > > to avoid using actions to load the data and pass it to the view. If you > > re-read my description of what I mean by 'push' vs. 'pull' rather than > > simply saying the terms mean something different it might help. > > Laurie, > > (Sorry for the late response -- just getting back from vacation). > > You might want to take a look at how Shale approaches your "pull" requirement. > > http://wiki.apache.org/struts/StrutsShale/ > > Being JSF based, Shale encourages you to associate a single bean with > each JSP page, where the bean can have more than one behavior (versus > a Struts 1.x action where the only behavior is to process the submit). > In particular, Shale supports a prerender() method that can be used > to pull the data that this page "knows" it needs from the model -- and > it sits right next to the logic (in a separate method) that processes > the subsequent submit. In Struts 1.x terms, prerender() is where > you'd do the things you currently do in a setup action, while the > normal event handling method (called an "action" in JSF parlance, but > it's a method instead of a class) does the follow-up updates to the > model. > > In Struts 1.x, you see this same idea directly implemented in Tiles, > via the Controller interface. It's also a dominant idea in ASP.Net, > Tapestry, and Spring MVC -- and it's sorta immortalized in the J2EE > design patterns lexicon as the View Helper pattern. > > I'd be interested to hear if this is close to what you had in mind, or > if it was something else again. > > Craig McClanahan > > > > > > > > I think I'll drop the topic now, before this degrades into a flame fest. > > > > L. > > > > Dakota Jack wrote: > > > > > I believe the point was nothing like this at all, Dave. Don't know > > > why you thought it was. Seems like you just thought this stuff up > > > separate to me. However, certainly I don't think that the issue > > > whether or not you are writing a CMS is relevant to the issues > > > discussed. I also have no idea why you went off on the XML stuff. > > > This is simply an issue of where work on the model should be. Your > > > discussion, so far as I can tell, is about something entirely > > > different and I have no idea where you got these issues. If these are > > > the issues, then you must be speaking some language with Ms. Harper > > > that I don't know. > > > > > > On 5/23/05, Dave Newton <[EMAIL PROTECTED]> wrote: > > > > > >>Dakota Jack wrote: > > >> > > >> > > >>>Just use some framework, like Struts. Write your actions and your > > >>>model to take are of this business and feed the data to the > > >>>appropriate scopes and objects. > > >>> > > >>> > > >> > > >>I believe the point was that this isn't an option. > > > > > > > > > > > > --------------------------------------------------------------------- > > 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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
