You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Michael Jouravlev <jm...@gmail.com> on 2005/10/13 18:46:42 UTC
View helpers a.k.a. "inverted" views
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
Re: View helpers a.k.a. "inverted" views
Posted by Michael Jouravlev <jm...@gmail.com>.
On 10/13/05, Ted Husted <te...@gmail.com> wrote:
> The Velocity Tools are a neat way to implement helpers.
>
> * http://jakarta.apache.org/velocity/tools/index.html
>
> Velocity Struts is an extension of the Velocity Tools that implements
> the Struts API as set of helper objects that are injected into the
> server page context. Very cool.
Thanks, I take a look at Velocity.
> I doubt that it would be difficult to use a custom tag or JSTL
> expression to fire a helper as the page was rendering. A kink with
> this strategy is the inverse of your forwarding issue. If something
> goes wrong while the page is rendering, it's too late to dispatch to
> another page.
Right, conceptually I prefer to navigate to action since action
represents a web resource to me, and JSP is just a view, and I can
have several views for an action. But the benefit of navigating
directly to JSP is to be able to include it in another JSP, and this
would work with currently available servlet engines. Including actions
that forward to JSP does not work in Tomcat, for example.
It is possible to dispatch to one or another page from within JSP,
therefore offloading portion of dispatching functionality to JSP. Does
not look nice conceptually, but works with servlet engines if I want
to embed a JSP fragment into another JSP page.
I think I can write a generic JSP view helper which would instantiate
action class and a form bean, initialize them, call execute() on
action, and then choose a proper JSP fragment to include. I will need
to read config info from struts-config, I have it all in the memory,
so it should be simple.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Ted Husted <te...@gmail.com>.
The Velocity Tools are a neat way to implement helpers.
* http://jakarta.apache.org/velocity/tools/index.html
Velocity Struts is an extension of the Velocity Tools that implements
the Struts API as set of helper objects that are injected into the
server page context. Very cool.
It's not on the roadmap, but something that was in the Jericho
whiteboard was the idea of being able to define arbitrary POJO objects
that would be automatically injected to one of the scopes, either for
some requests for all requests, so that they would seem to be
"implicit" to the page (like the Velocity Tools).
I doubt that it would be difficult to use a custom tag or JSTL
expression to fire a helper as the page was rendering. A kink with
this strategy is the inverse of your forwarding issue. If something
goes wrong while the page is rendering, it's too late to dispatch to
another page.
-Ted.
On 10/13/05, Michael Jouravlev <jm...@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
>
>
--
HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Ted Husted <te...@gmail.com>.
On 10/13/05, Nathan Bubna <nb...@gmail.com> wrote:
> sounds good. but i'm not sure i follow totally... has this been done?
> or is it just planned? really, i'm not up to speed on Struts 1.3 at
> all.
It's on the list, along with some other items, but I wanted to roll
Struts 1.3.0 first, in full subproject mode, before getting off on
anything else.
> just want to be sure i understand here... are you wanting to bring
> Velocity(Tools) integration code over to the Core or merely the code
> we use to access Struts resources?
>
> granted, the two aren't clearly delineated in VelocityStruts, but in
> general the integration-ish code is in the actual tool classes and
> exists to put a Velocity(Tools) friendly API on Struts resources. the
> StrutsUtils class is largely where we access struts resources (and i
> believe it originated in code from you. :)
Haven't decided on the implementation, but I think the idea is sound.
We need to wean people away from this idea that tags/controls should
access the contexts directly to obtain framework services. The
framework should hand them an API object (or helper or tool), and then
the controls should get it form there.
Under credit where credit is due, the API object idea was Geir's. He
was surprised that we didn't have one already :) So, back in the day,
I created a prototype to serve as a reference for the Velocity Struts
initiative, which we still have lying around.
* http://tinyurl.com/97zbh
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Nathan Bubna <nb...@gmail.com>.
On 10/13/05, Ted Husted <te...@gmail.com> wrote:
> On 10/13/05, Nathan Bubna <nb...@gmail.com> wrote:
> > 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. :)
>
> For Struts 1.3, I wouldn't trying to make the VelocityStruts tools obsolete :)
?
> The idea with this 1.3 agenda item
>
> * ViewContext - A Commons Chain Context that implements the combined
> VelocityStruts logical API (same signatures).
>
> 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.
sounds good. but i'm not sure i follow totally... has this been done?
or is it just planned? really, i'm not up to speed on Struts 1.3 at
all.
> Since VelocityStruts has already solved this problem :), I'd like to
> adopt and adapt that code so that it is part of the Core framework.
just want to be sure i understand here... are you wanting to bring
Velocity(Tools) integration code over to the Core or merely the code
we use to access Struts resources?
granted, the two aren't clearly delineated in VelocityStruts, but in
general the integration-ish code is in the actual tool classes and
exists to put a Velocity(Tools) friendly API on Struts resources. the
StrutsUtils class is largely where we access struts resources (and i
believe it originated in code from you. :)
> The big implementation question would be whether to use several
> objects, as Velocity Struts does, or just roll them back into one.
yep. that's a big one. we break them up because it seems
conceptually clearer and simpler to have $link, $text, $errors, and
such than to have the extra layer of $struts.link, $struts.text, and
so on. but this may not matter so much if you are presenting an API
to tag (or tool) developers rather than page designers.
also, a big advantage of splitting ours up is that we are then able to
have the StrutsLinkTool extend VelocityView's LinkTool and thus
leverage that code, and we can also offer the SecureLinkTool as an
optional drop in replacement for the StrutsLinkTool. of course, on
the latter, i suppose you could combine them all and make the
https/http option be a matter of tool config rather than tool choice.
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Hubert Rabago <hr...@gmail.com>.
On 10/14/05, Michael Jouravlev <jm...@gmail.com> wrote:
> >
> > Or the other way around. Request or session-scoped actions that have
> > instance variables that get populated from the incoming action. I've
> > done the request/session-scoped action before, and with BeanUtils or
> > FormDef, populating the instance fields is easy. Combine this with
> > DispatchAction or ActionDispatcher and you've gone back to The Object
> > which combine data and methods.
> >
> > Hubert
>
> I am all in either for one or another. I am thinking of doing it
> myself. Hubert, maybe you could share some code of yours ;-) if you
> already went down this path.
Well, if you check out the msg I sent to the Struts + AJAX thread over
at user@, you'll see where my time is going right now. However, I
meant to write a demo app illustrating this very concept for some time
now, and now that someone has expressed interest, I think I'll go
ahead with it.
> But I don't want things *replacing* things. The point of maintaining
> Struts Classic is to keep compatibility, while enhancing it. I hope,
> that this new context object or whatever you call it, will not
> deprecate what we have now, because a lot of people depend on it.
>
> Michael.
>
The data+behavior action I've used did replace the CreateAction part
of the chain (and led me to
http://svn.apache.org/viewcvs?rev=209987&view=rev), but that was about
it. I specified the scope using the <set-property> that Joe
introduced.
The updated validator behavior I'm playing with uses a forked set of
taglibs. I haven't modified much, so I may get away with overriding
certain tags instead, but for my POC I just went ahead and copied
everything right away. The itch needed scratching ASAP.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Michael Jouravlev <jm...@gmail.com>.
On 10/14/05, Hubert Rabago <hr...@gmail.com> wrote:
> On 10/14/05, Ted Husted <te...@gmail.com> wrote:
> > On 10/13/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > > 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)
> >
> > The question is getting there from here -- without leaving anyone
> > behind. One reason we're changing the request processor is give people
> > more flexibility in deciding how things work. As it stands, these sort
> > of changes are slated for the Struts 1.5.x series.
> >
> > * http://struts.apache.org/milestones.html
> >
> > A simple way to accomplish some of this is to put an execute method on
> > an ActionForm and then have the Action delegate to the ActionForm.
> >
> > -Ted.
>
> Or the other way around. Request or session-scoped actions that have
> instance variables that get populated from the incoming action. I've
> done the request/session-scoped action before, and with BeanUtils or
> FormDef, populating the instance fields is easy. Combine this with
> DispatchAction or ActionDispatcher and you've gone back to The Object
> which combine data and methods.
>
> Hubert
I am all in either for one or another. I am thinking of doing it
myself. Hubert, maybe you could share some code of yours ;-) if you
already went down this path.
But I don't want things *replacing* things. The point of maintaining
Struts Classic is to keep compatibility, while enhancing it. I hope,
that this new context object or whatever you call it, will not
deprecate what we have now, because a lot of people depend on it.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Hubert Rabago <hr...@gmail.com>.
On 10/14/05, Ted Husted <te...@gmail.com> wrote:
> On 10/13/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > 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)
>
> The question is getting there from here -- without leaving anyone
> behind. One reason we're changing the request processor is give people
> more flexibility in deciding how things work. As it stands, these sort
> of changes are slated for the Struts 1.5.x series.
>
> * http://struts.apache.org/milestones.html
>
> A simple way to accomplish some of this is to put an execute method on
> an ActionForm and then have the Action delegate to the ActionForm.
>
> -Ted.
Or the other way around. Request or session-scoped actions that have
instance variables that get populated from the incoming action. I've
done the request/session-scoped action before, and with BeanUtils or
FormDef, populating the instance fields is easy. Combine this with
DispatchAction or ActionDispatcher and you've gone back to The Object
which combine data and methods.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Ted Husted <te...@gmail.com>.
On 10/13/05, Michael Jouravlev <jm...@gmail.com> wrote:
> 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)
The question is getting there from here -- without leaving anyone
behind. One reason we're changing the request processor is give people
more flexibility in deciding how things work. As it stands, these sort
of changes are slated for the Struts 1.5.x series.
* http://struts.apache.org/milestones.html
A simple way to accomplish some of this is to put an execute method on
an ActionForm and then have the Action delegate to the ActionForm.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Michael Jouravlev <jm...@gmail.com>.
On 10/13/05, Don Brown <do...@gmail.com> 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 <tf...@tfenne.com> 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 <te...@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Ted Husted <te...@gmail.com>.
On 10/13/05, Nathan Bubna <nb...@gmail.com> wrote:
> 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. :)
For Struts 1.3, I wouldn't trying to make the VelocityStruts tools obsolete :)
The idea with this 1.3 agenda item
* ViewContext - A Commons Chain Context that implements the combined
VelocityStruts logical API (same signatures).
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.
Since VelocityStruts has already solved this problem :), I'd like to
adopt and adapt that code so that it is part of the Core framework.
The big implementation question would be whether to use several
objects, as Velocity Struts does, or just roll them back into one.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Nathan Bubna <nb...@gmail.com>.
On 10/13/05, Don Brown <do...@gmail.com> 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 <jm...@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
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Nathan Bubna <nb...@gmail.com>.
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 <tf...@tfenne.com> 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 <jm...@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
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Tim Fennell <tf...@tfenne.com>.
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 <jm...@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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: View helpers a.k.a. "inverted" views
Posted by Don Brown <do...@gmail.com>.
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 <jm...@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
>
>