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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
