Barry Davies schrieb: > Sebastian, I've been trying to collect my thoughts on something very analogous to your dialogScope, tho I've been calling it conversationScope or ConversationState in my discussions with colleagues. I haven't completely connected the dots in my own thinking on the subject, so apologies for the 1/2-baked ideas, but your post prodded me into commentary. My idea was a bit more modest, although I'm not sure how much it would save in terms of implementation complexity. I'd be content with a Stripes-provided facility for a conversation scoped to GETting or POSTing between different event handlers on the same ActionBean. So if you have an ActionBean that has a view() event handler, with delete(), saveDraft(), and signOff() eventhandlers driven by buttons on the form ultimately rendered in response to the view() event handler, you'd have a convenient state to hold, say, entities to be merge() or lock() into your current Hibernate Session as part of > optimistic offline concurrency checks. This would assist the view() to signOff() transition, as well as any transitions due to things like validation errors, or indeed the StaleData (or whatever its called) exception in the event of a failed version check. Since its scoped not just to a particular eventHandler, if someone encounters validation error when trying to signOff(), they could switch to saveDraft() for its more permissive validation, and still retain the conversationScope.
Hibernate is another interesting option. I progressed quite far. The possibility to add interceptors to Stripes allows to integrate things very easy. > This would seem to dovetail nicely with how I think people are using @Wizard ActionBeans, though my experience with that > feature is limited. I'm thinking that if an action bean writes into the scope or explicitly does something either thru API or Annotation, the scope is created with something like __fsk696969 created on your behalf, with you not needing to give that artifact a particular name. I'm also thinking that successful completion of any eventhandler that doesn't > write into the conversationScope or explicitly call for it to be continued would clear it out, without the need for further developer intervention. I'm thinking that any navigation to a different ActionBean or JSP should clear out this conversation state. The problem is, if you have multiple windows open. The second window will destroy your first windows scope. Best Regards Sebastian ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-development
