struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hermod Opstvedt <>
Subject SV: [shale] Best practice for passing information between views in Shale
Date Sat, 25 Mar 2006 08:25:34 GMT

Thanks, I looked at Gary's Rolodex example, and the QueryParam valueholder
seems like another way of doing it. This also allows for moving between
arbitrary pages. Not quite JSFish though.

I think that the <t:saveState> might be what I want here.


-----Opprinnelig melding-----
Fra: [] På vegne av Craig
Sendt: 25. mars 2006 03:22
Til: Struts Users Mailing List;
Emne: Re: [shale] Best practice for passing information between views in

On 3/24/06, Hermod Opstvedt <> wrote:
> Hi
> I have scenario where information on one page is used a basis for another
> page. What would be best practice for transferring information from page1
> to
> page2, where both pages are request scoped. Declaring this as a dialog
> flow,
> or using a session scoped bean as a value holder?

There's a few options, including the ones below.  Let's call the page that
processed the form submit page1 and the one to be rendered as page2.

*  Define a public property on page1's backing bean, store the info
  there, and code page2's backing bean (or binding expressions)
  to call it.  This works, but has a significant disadvantage -- it works
  only when going from page1 to page2, but not page3 to page2.

* Similar to the first solution, but put the public property on page2
  instead of on page1.  There is still a coupling disadvantage, but
  you can at least get to page2 from multiple origins.

* Use a dialog state.  Quite nice for this, but pretty complex to set up
  if all you need is to pass the data along.

* Use an arbitrary request attribute.  This is more typical of what you'd
  do in non-JSF applications, and works fine.  To put something into
  these attributes with key "foo", you'd do:

    getExternalContext().getRequestMap().put("foo", bar);

NOTE - i'm evaluating ways to emulate what Ruby on Rails does with the
"flash" concept to address the "need it for one more request", but could
perhaps also help for this scenario in the current request.

Another goes for maintaining state between accesses to the same page. Using
> hidden inputfields or a session scoped bean as a value holder?

Both of those work ... the JSF-ish way to do the hidden input field would be
an <h:inputHidden> component.

If you're using MyFaces, you should also check out <t:saveState> for this.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message