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. ... > 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 think this is push vs pull. You can navigate to an action, choose a view and pull needed data into it. Is it push or pull? View helpers is not about just getting the data, it is about how the controller/dispathcher is called. *If* you regard JSP as a *view* technology or in other words, as data-aware HTML, then the difference is conceptual. In this case dispatcher (action class + form bean + whatever else) represents a web resource, possibly stateful, possibly with several views. While JSP page is, well, just a view. Therefore navigating to an action and then rendering a view is a proper (for me, at least) approach, where a user selects a web resource, and an action renders a view. *User don't select a view, a web resource does*. Navigating to JSP page and pulling data into it means navigating to a concrete view instead of navigating to a resource, which is just plain wrong if you ask me. But, if you regard JSP as both *view and controller*, then view helper/pull model allows to do neat things with <jsp:include>. The proper [sub]view can be selected by JSP, using scriptlets or tags. This means offloading part of controller's job to JSP. I don't think this is a good concept, but it works with currently available servlet engines, so I might consider using it. On 10/13/05, Tim Fennell <[EMAIL PROTECTED]> wrote: > 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. When you view something, you want to see a resource content, not a specific view of your choice. You don't know what state the resource is in, so you cannot assume that view that you navigating to, is valid or appropriate for current resource's state. This is, if you consider JSP page *just a view*. On 10/13/05, Ted Husted <[EMAIL PROTECTED]> wrote: > is to eliminate the need for tags to wander all over the contexts > looking for this and that. Instead, it will all be in a single object > in request scope. (Which in turn might access other objects in session > or application scope.) > > Accessing Struts components directly would be deprecated, and support > removed in a later release. Access through the ViewContext would be > cannonical, and tag libs support Struts would need to upgrade. What about accessing ActionForm properties??? A lot of people do this, me included. The whole idea of using session-scoped ActionForm in Struts Dialogs, is that ActionForm keeps state during conversation with resource. Input goes into actionform automatially (RequestProcessor.populate), its content may be changed by action, and then displayed through JSP. Do you want to remove that???? Do I need to store my stuff somewhere again, and to copy it from form or whatever input buffer would be, to that context object??? Instead, Action and ActionForm should be combined into one object, which can be: * stateful, if needed * can be accessed from JSP * can be automatically populated * contaned lifecycle methods (via interface, like in Shale) * can respond to input events (like DispatchAction) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
