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. 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.
I think that our ideas could live together fairly easily, potentially only
differentiating on whether the scope is explicitly referred to by name
(allowing multiple JSPs or ActionBeans to participate in the conversation).
Then my idea is a potentially handy default case to that bigger idea. What do
you guys out there think. Would this be a handy feature to have around?
- BD aka RJ
----- Original Message ----
From: Sebastian Hennebrüder <[EMAIL PROTECTED]>
To: Stripes Development List <[email protected]>
Sent: Friday, July 27, 2007 8:07:09 AM
Subject: [Stripes-dev] Dialog scope
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I will implement a new scope in my application and are thinking to
integrate this directly into stripes. The idea is actually inspired by
Jboss Seam.
In addition to session, request or flashScope, I would like to have a
scope which lives across a number of request but not as long as the
session.
I would like to call it dialogue scope.
The following work through describes what it should do:
1)
Add annotation @createDialogScope to a action method. This will create a
unique scope in the current session.
2)
load data from db and put a list of objects in this scope
3)
dialogue is rendered and scope reference is added to links (like
flashscope) and forms (like wizard).
4)
page through the list, any kind of dialogue to delete entries, ...
5)
add a annotation @deleteDialogScope to another action
this action is called at the end of the dialogue and will delete the scope
Additional features:
- - methods to get all current scopes, allowing to show current open
dialogues
- - a annotation @defaultDialogPage, allowing to jump to a dialog, when I
displayed all open dialogues
- - a current url to allow to jump to the dialog at the current position,
if I accidentally closed a second browser windows
- - methods to delete dialogs and scope
I know that a scope might become abandoned but I think the additional
method could allow developers to provide methods to show open dialogs.
What do you think?
- --
Best Regards / Viele Grüße
Sebastian Hennebrueder
- -----
http://www.laliluna.de
Laliluna.de, Berliner Strasse 22, 61118 Bad Vilbel, Germany
* Java Software Development, Support
* Tutorials for JSP, JavaServer Faces, Struts, Hibernate and EJB
* Seminars and education at reasonable prices
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGqe39j5T0w9sqg4kRAu9tAJ9VN9U4C5Q+USaxwktAGB6Ey1ERTQCfdELo
z6fu1fv8Xq5tEN1Yt31jvhc=
=a0UR
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
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
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222-------------------------------------------------------------------------
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
