struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [shale] starting points and Use Cases issues
Date Mon, 21 Nov 2005 17:08:21 GMT
On 11/20/05, Laurie Harper <> wrote:
> 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?

At the end of the day, back buttons need to be addressed at the JSF level
for use cases when you're using it directly (as well as Shale needing to
address it for the specific case of dialogs). I know there's been some work
done in the JSF RI for 1.2 that targets this problem (and some of it might
have been backported to the 1.1 RI available at <>;
haven't had time to check yet).

For Shale, I see that Rahul has submitted a proposed patch for dialogs and
the back button, although my inclination is to defer all those fixes to
1.0.1 so we can actually get a milestone out the door -- with appropriate

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 ;-)



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