Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of craigmcc@gmail.com designates
 64.233.184.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references;
        b=rTSaqlA7sHUy+vLC4RnSzuSptfa3VlcQmUf/dspH3PtQNo8UMUovKkxOCu6mMd63T3vwDM1TXLoKJPHVps/tjegG6UsafNAuNu6sOtyGeLyOeFx5Vff5FBTKFM3BUqsL8YprOWB5GN4QXpRyqpTjX402PVjDXBwX+J1qfAKSioE=
Message-ID: <f8b39ace0602141325y68a5fc59qbbbbdb79bb82d0ee@mail.gmail.com>
Date: Tue, 14 Feb 2006 13:25:42 -0800
From: Craig McClanahan <craigmcc@apache.org>
Sender: craigmcc@gmail.com
To: Struts Users Mailing List <user@struts.apache.org>
Subject: Re: [shale] datatables request scope
In-Reply-To: 
 <67538F65C12991418BE2801290008A070230F374@ilnort1msgusr15.ITServices.sbc.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_7870_18906407.1139952342772"
References: 
 <67538F65C12991418BE2801290008A070230F374@ilnort1msgusr15.ITServices.sbc.com>

------=_Part_7870_18906407.1139952342772
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 a=
s
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=3D"#{flash.savedCustomerName}"/>

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

- Brendan


Craig

------=_Part_7870_18906407.1139952342772--