struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: [shale] datatables request scope
Date Tue, 14 Feb 2006 21:25:42 GMT
On 2/14/06, CONNER, BRENDAN (SBCSI) <bc1378@att.com> wrote:
>
> Ah, OK.  Then the <t:saveState> component from MyFaces would be more
> appropriate for the problem being discussed.  We've used this in several
> applications, with no problems.  All of our beans (except maybe two of
> them, that contain more static values) are request scope, but they carry
> their values through multiple pages of a conversation.


All of the patterns that work for non-JSF-based webapps all work with JSF as
well -- for example:
* session scope state variables
* hidden fields in input forms
* request parameters on generated URLs
* cookies

Shale Dialogs is an instance of the first one, in that it gives you a sort
of scope "longer than a request, but shorter than a session", without you
having to be responsible for cleanup.  It's nice when you have your
application organized into a series of "conversations" with the user that
have well defined beginning and ending points.

One idea I've seen discussed, but haven't seen actually implemented yet,
would be a JSF-specific implementation of the "flash" concept in RoR, where
it keeps state information around for exactly *one* more request for you.
It should be easy to do this with a specialized variable resolver or
something ... I'll think about how to do that when dialogs are heavier
weight than you really need.  Something along the lines of this in the
second page:

   <h:outputText value="#{flash.savedCustomerName}"/>

where "savedCustomerName" was stored away (until the next request) by some
TBD mechanism.

- Brendan


Craig

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message