struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurie Harper <lau...@holoweb.net>
Subject Re: [shale] starting points and Use Cases issues
Date Mon, 21 Nov 2005 04:29:08 GMT
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


Mime
View raw message