Ive helped develop another web framework (component based, but that doesnt
actually matter in regard to this) where we had the following scopes or
contexts as we call them:
RequestContext, which models the current Servlet Request
PageContext, which survives as long as the requests keeps going to the same
Page (same Actionbean in Stripes case).
WindowContext, which relates to the actual browser window. This one was
possible to do, since we can control creation of new browser windows.
Otherwise this scope is dangerous as a Ctrl+N in Internet Explorer 6 just
will create two browser windows which share the same WindowContext
ConversationContext, which models a conversation between as many
ActionBean/events as you wish. Conversation can get tricky when it comes to
back button etc. Also how should it relate to transaction demarcation (this
is an interesting subject, but probably outside Stripes scope).
SessionContext, comparable to the Session
ApplicationContext, comparable to the ServletContext
The cool thing about these contexts is that you can specialize them to fit
suite your application.
/Jeppe
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Barry Davies
Sent: 1. august 2007 04:25
To: Stripes Development List
Subject: Re: [Stripes-dev] Dialog scope
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
_____
Looking for a deal? Find
<http://us.rd.yahoo.com/evt=47094/*http:/farechase.yahoo.com/;_ylc=X3oDMTFic
DJoNDllBF9TAzk3NDA3NTg5BHBvcwMxMwRzZWMDZ3JvdXBzBHNsawNlbWFpbC1uY20-> great
prices on flights and hotels with Yahoo! FareChase.
__________ NOD32 2430 (20070731) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
-------------------------------------------------------------------------
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
