This is also an area I like to discuss but I do not have any implementation
nor the requirement yet to implement alternate scopes.
I've made an earlier posting on this topic giving my thoughts, which I
repeat below.
--- start of extract ---
(...)
This has suggested me the notion of contexts, some being standards (request,
session, etc.), others being custom defined (like your notion of workflow).
Each context type would carry different behavior in terms of:
- how many context of this type can be started during a session
- how many context of this type can run concurrently in a session
- whether going through the starting point of a context will create a new
instance of a context, reuse an existing one, etc.
- critical section handling (useful for form submission and transaction
processing)
- etc.
We haven't given any further thoughts than this, and certainly not in terms
of implementation. But the need has been identified and put in a list of
things to look into someday.
I'd be curious to know whether anybody else agrees with this idea of joining
together into the same concept of custom contexts, things like : workflow,
sensitive forms, and transaction integrity.
--- end of extract ---
Like you suggest, those scopes should most likely be stored in the session
or application contexts. One thing that I think should be considered is to
combine the notion of transaction integrity (usually implemented with a
token) with the notion of alternate scope (also usually represented with a
token).
Fr.
-----Original Message-----
From: Jonathan Asbell [mailto:[EMAIL PROTECTED]]
Sent: 21 June 2001 04:06
To: [EMAIL PROTECTED]
Subject: Opening up a thread on ALTERNATE SCOPES
Hello all. We were talking about workflow a few weeks ago and the
conversation dissipated. I am trying to open it up again because I have
found a need for more scopes, and a need to implement these new scopes in
the next few months. I am interested specifically in how it can be
implemented in Struts. Let me begin with the new scopes.
1) Workflow scope within an application
Store values from the first step until the final step and then get rid of
the values
You could probably use an adaptor, hide implementation from the developer,
and store this scope inside the "session" scope
Example - within an application store a value Do Activity 1, then do
Activity 2, then do Activity 3, then throw out the value
2) Workflow between applications (mentioned by Dan Connelly earlier)
Store values from the first step until the final step and then get rid of
the values
You could probably use an adaptor, hide implementation from the developer,
and store this scope inside the "application" scope
Example - store a value and do Activity 1 in Application 1, then do Activity
2 in Application 2, then do Activity 3 in Application 3, then throw out the
value
3) Sub-Application scope
Store values that pertain to a sub-directory within an application
You could probably use an adaptor, hide implementation from the developer,
and store this scope inside the "session" or "application" scope though I'm
not sure which would be more appropriate.
Example - Your applcation is a magazine which has 4 different sections, and
you want to store values only pertaining to each section. When you leave
the section the value is not visible, and may or may not disappear
(depending on what you want to do).
************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***********************************************************************
