Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of jak-struts-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@struts.apache.org
From: Laurie Harper <laurie@holoweb.net>
Subject: Re: [shale] starting points and Use Cases issues
Date: Sun, 20 Nov 2005 23:29:08 -0500
Lines: 30
Message-ID: <dlriel$fof$1@sea.gmane.org>
References: <dlkg0i$9fg$1@sea.gmane.org>
	 <7CF0E4C9-E171-4C1A-9863-FD23700BEAA4@apache.org>
 <f8b39ace0511180728m53621dc2ufe3c9b6fe8a961d@mail.gmail.com>
Reply-To: laurie-list-noreply@holoweb.net
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
In-Reply-To: <f8b39ace0511180728m53621dc2ufe3c9b6fe8a961d@mail.gmail.com>
Sender: news <news@sea.gmane.org>

Craig McClanahan wrote:
> And, as to dialogs, yes ... in the current implementation, back buttons are
> death (as well as multiple simultaneous dialogs). That's very high on my
> priority list for *after* the whole darn thing is stable enough for a
> 1.0.0alpha-quality milestone.

The more I play with Faces, the more I suspect that the back button is 
going to be pretty dangerous for and Faces app... I've figured out that 
telling the JSF implementation to persist component state on the client 
rather than the server helps a lot, but it still seems *very* easy to 
get into an inconsistent state if the user jumps back in their browser 
history (via the back button or otherwise)...

I'm guessing there are patterns and best practices that can be used in 
writing backing beans, action handler methods and such that can help 
mitigate this but, realistically, how difficult is it to write faces 
apps that are robust in the face of the back button/browser 
history/bookmarks? I know the toy app I wrote on Friday isn't, and I 
don't yet know enough to figure out how to make it so.

Now the really hard question: is it possible to achieve the same goals 
*without* storing state on the client side?

And finally: does (or could) Shale in any way help with any of this?

I'm definately thinking about migrating to JSF if I can figure out how 
to solve a few concerns like these, so it looks like that one sleepless 
night Thursday/Friday may be going to cost me many more to come ;-)

L.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org