You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jonathan Asbell <ja...@i-2000.com> on 2001/06/21 04:06:24 UTC
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).
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Jonathan <ja...@i-2000.com>.
Hello Paul. I didnt know anything about graphs. Thanks for explaining.
So how do you make these graphs? How do you link things in this fashion. I
am really interested. Any links you can send me about this?
----- Original Message -----
From: "Paul Speed" <Pa...@metrixpoint.com>
To: <st...@jakarta.apache.org>
Sent: Thursday, June 21, 2001 12:53 PM
Subject: Re: Opening up a thread on ALTERNATE SCOPES
> A graph is a data structure where nodes are linked together. One
> node is linked to several other nodes and so on. A directed graph is
> a graph where the links have a specific direction. A tree is a special
> form of graph (usually directed) that only branches in one direction.
> In other words, a child node will never link to something higher in
> the tree. It only branches down.
>
> For workflow types of applications the nodes of a graph often represent
> states in a workflow. The links between the nodes represent
> transitions. Sometimes these transitions also have functionality
> attached to them. It is often necessary to have circular workflows
> or workflows that transition to another step outside of the normal
> flow of the current "process". This makes a tree a poor data
> structure to use since it cannot loop back on itself.
>
> Although, I now realize that since we aren't working from the same set
> of definitions, I shouldn't have taken your "tree" reference to be so
> specific.
>
> -Paul Speed
>
> Jonathan Asbell wrote:
> >
> > Can you describe what you mean by graph. Do you mean a HashMap or List?
> > How do you "jump"? How do you go follow decisions and results?
> >
> > ----- Original Message -----
> > From: "Paul Speed" <Pa...@metrixpoint.com>
> > To: <st...@jakarta.apache.org>
> > Sent: Thursday, June 21, 2001 2:24 AM
> > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> >
> > > Just one small point...
> > >
> > > In all my (admittedly brief compared to some) travels through workflow
> > > land, I've never had a workflow that was specifically tree. They all
> > > end up forming a graph at some point.
> > >
> > > One could argue that you can just have jump points from one branch to
> > > another, but in my experience, after many iterations the tree becomes
> > > more of a hinderance than a boon as jump points become more frequent.
> > >
> > > It might be better to design it to be a graph structure from the
> > > beginning.
> > >
> > > -Paul Speed
> > >
> > > Jonathan Asbell wrote:
> > > >
> > > > Since my needs are for web container persistence, let me make a
> > suggestion
> > > > in that area.
> > > > An object called WorkflowPath could be created with configurable
values
> > > > sucked up from a file. The values could be some kind of tree, like
a
> > > > decision/process tree. The WorkflowPath object would be stored in
> > > > application scope, or a custom scope as mentioned below in the
original
> > > > post, such as Sub-Application scope. When you begin a process you
grab
> > the
> > > > WorkflowPath from the scope stored under a name like
"loginWorkflow",
> > and
> > > > you would query it for the next step in the decision/process tree.
It
> > would
> > > > be nice maybe to have a pointer as to where you are in the sequence
of
> > > > things. Anyone want to add to this? Anyone want to dis this? Are
you
> > all
> > > > asleep on this warm New York Summer night? =)
> > > >
> > > > ----- Original Message -----
> > > > From: "Geir Magnusson Jr." <ge...@optonline.net>
> > > > To: <st...@jakarta.apache.org>
> > > > Sent: Wednesday, June 20, 2001 11:25 PM
> > > > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> > > >
> > > > > Jonathan Asbell wrote:
> > > > > >
> > > > > > Persistent storage is an option too. I was hoping, however to
limit
> > > > calls
> > > > > > through the enterprise parts and database.
> > > > >
> > > > > Why?
> > > > >
> > > > > > You could argue that it belongs
> > > > > > there because the database is the central location holding all
data
> > and
> > > > > > information and therefore should hold workflow info, especially
in
> > the
> > > > face
> > > > > > of changing services/activities. However, must I consult the
> > database
> > > > or a
> > > > > > db developer each time I want to add, change, or see anything?
That
> > is
> > > > a
> > > > > > time waster.
> > > > >
> > > > > Not really. I mean, I guess it's your design requirements. I
would
> > > > > want it to be that a user in a process (or a process itself) has
no
> > > > > requirement of 'immediate completion' - i.e. some part of the flow
can
> > > > > take a while.
> > > > >
> > > > > So then if the servlet container goes down, I don't care. No
state
> > > > > lost.
> > > > >
> > > > > >
> > > > > > If you were not going to use persistent storage, how would you
do
> > it?
> > > > >
> > > > > For what I want to do, i can't really escape it. Somewhere,
something
> > > > > has to remember the state - assume the servlet container is going
down
> > > > > at some point...
> > > > >
> > > > > geir
> > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Geir Magnusson Jr." <ge...@optonline.net>
> > > > > > To: <st...@jakarta.apache.org>
> > > > > > Sent: Wednesday, June 20, 2001 10:17 PM
> > > > > > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> > > > > >
> > > > > > > Can I ask why you don't go with persistant storage, like a
rdbms?
> > I
> > > > > > > have been thinking about workflow recently as well, although
not
> > > > > > > specifically w/in struts, and I believe that for the general
> > solution,
> > > > > > > where someone can come back a long time later and resume, or
be it
> > an
> > > > > > > automated process, persistant storage would be required.
> > > > > > >
> > > > > > > geir
> > > > > > >
> > > > > > >
> > > > > > > > Jonathan Asbell wrote:
> > > > > > > >
> > > > > > > > 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).
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Geir Magnusson Jr.
geirm@optonline.net
> > > > > > > System and Software Consulting
> > > > > > > Developing for the web? See
http://jakarta.apache.org/velocity/
> > > > > > > You have a genius for suggesting things I've come a cropper
with!
> > > > > > >
> > > > >
> > > > > --
> > > > > Geir Magnusson Jr. geirm@optonline.net
> > > > > System and Software Consulting
> > > > > Developing for the web? See http://jakarta.apache.org/velocity/
> > > > > You have a genius for suggesting things I've come a cropper with!
> > > > >
> > >
>
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Paul Speed <Pa...@metrixpoint.com>.
A graph is a data structure where nodes are linked together. One
node is linked to several other nodes and so on. A directed graph is
a graph where the links have a specific direction. A tree is a special
form of graph (usually directed) that only branches in one direction.
In other words, a child node will never link to something higher in
the tree. It only branches down.
For workflow types of applications the nodes of a graph often represent
states in a workflow. The links between the nodes represent
transitions. Sometimes these transitions also have functionality
attached to them. It is often necessary to have circular workflows
or workflows that transition to another step outside of the normal
flow of the current "process". This makes a tree a poor data
structure to use since it cannot loop back on itself.
Although, I now realize that since we aren't working from the same set
of definitions, I shouldn't have taken your "tree" reference to be so
specific.
-Paul Speed
Jonathan Asbell wrote:
>
> Can you describe what you mean by graph. Do you mean a HashMap or List?
> How do you "jump"? How do you go follow decisions and results?
>
> ----- Original Message -----
> From: "Paul Speed" <Pa...@metrixpoint.com>
> To: <st...@jakarta.apache.org>
> Sent: Thursday, June 21, 2001 2:24 AM
> Subject: Re: Opening up a thread on ALTERNATE SCOPES
>
> > Just one small point...
> >
> > In all my (admittedly brief compared to some) travels through workflow
> > land, I've never had a workflow that was specifically tree. They all
> > end up forming a graph at some point.
> >
> > One could argue that you can just have jump points from one branch to
> > another, but in my experience, after many iterations the tree becomes
> > more of a hinderance than a boon as jump points become more frequent.
> >
> > It might be better to design it to be a graph structure from the
> > beginning.
> >
> > -Paul Speed
> >
> > Jonathan Asbell wrote:
> > >
> > > Since my needs are for web container persistence, let me make a
> suggestion
> > > in that area.
> > > An object called WorkflowPath could be created with configurable values
> > > sucked up from a file. The values could be some kind of tree, like a
> > > decision/process tree. The WorkflowPath object would be stored in
> > > application scope, or a custom scope as mentioned below in the original
> > > post, such as Sub-Application scope. When you begin a process you grab
> the
> > > WorkflowPath from the scope stored under a name like "loginWorkflow",
> and
> > > you would query it for the next step in the decision/process tree. It
> would
> > > be nice maybe to have a pointer as to where you are in the sequence of
> > > things. Anyone want to add to this? Anyone want to dis this? Are you
> all
> > > asleep on this warm New York Summer night? =)
> > >
> > > ----- Original Message -----
> > > From: "Geir Magnusson Jr." <ge...@optonline.net>
> > > To: <st...@jakarta.apache.org>
> > > Sent: Wednesday, June 20, 2001 11:25 PM
> > > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> > >
> > > > Jonathan Asbell wrote:
> > > > >
> > > > > Persistent storage is an option too. I was hoping, however to limit
> > > calls
> > > > > through the enterprise parts and database.
> > > >
> > > > Why?
> > > >
> > > > > You could argue that it belongs
> > > > > there because the database is the central location holding all data
> and
> > > > > information and therefore should hold workflow info, especially in
> the
> > > face
> > > > > of changing services/activities. However, must I consult the
> database
> > > or a
> > > > > db developer each time I want to add, change, or see anything? That
> is
> > > a
> > > > > time waster.
> > > >
> > > > Not really. I mean, I guess it's your design requirements. I would
> > > > want it to be that a user in a process (or a process itself) has no
> > > > requirement of 'immediate completion' - i.e. some part of the flow can
> > > > take a while.
> > > >
> > > > So then if the servlet container goes down, I don't care. No state
> > > > lost.
> > > >
> > > > >
> > > > > If you were not going to use persistent storage, how would you do
> it?
> > > >
> > > > For what I want to do, i can't really escape it. Somewhere, something
> > > > has to remember the state - assume the servlet container is going down
> > > > at some point...
> > > >
> > > > geir
> > > >
> > > > > ----- Original Message -----
> > > > > From: "Geir Magnusson Jr." <ge...@optonline.net>
> > > > > To: <st...@jakarta.apache.org>
> > > > > Sent: Wednesday, June 20, 2001 10:17 PM
> > > > > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> > > > >
> > > > > > Can I ask why you don't go with persistant storage, like a rdbms?
> I
> > > > > > have been thinking about workflow recently as well, although not
> > > > > > specifically w/in struts, and I believe that for the general
> solution,
> > > > > > where someone can come back a long time later and resume, or be it
> an
> > > > > > automated process, persistant storage would be required.
> > > > > >
> > > > > > geir
> > > > > >
> > > > > >
> > > > > > > Jonathan Asbell wrote:
> > > > > > >
> > > > > > > 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).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Geir Magnusson Jr. geirm@optonline.net
> > > > > > System and Software Consulting
> > > > > > Developing for the web? See http://jakarta.apache.org/velocity/
> > > > > > You have a genius for suggesting things I've come a cropper with!
> > > > > >
> > > >
> > > > --
> > > > Geir Magnusson Jr. geirm@optonline.net
> > > > System and Software Consulting
> > > > Developing for the web? See http://jakarta.apache.org/velocity/
> > > > You have a genius for suggesting things I've come a cropper with!
> > > >
> >
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Jonathan Asbell <ja...@i-2000.com>.
Can you describe what you mean by graph. Do you mean a HashMap or List?
How do you "jump"? How do you go follow decisions and results?
----- Original Message -----
From: "Paul Speed" <Pa...@metrixpoint.com>
To: <st...@jakarta.apache.org>
Sent: Thursday, June 21, 2001 2:24 AM
Subject: Re: Opening up a thread on ALTERNATE SCOPES
> Just one small point...
>
> In all my (admittedly brief compared to some) travels through workflow
> land, I've never had a workflow that was specifically tree. They all
> end up forming a graph at some point.
>
> One could argue that you can just have jump points from one branch to
> another, but in my experience, after many iterations the tree becomes
> more of a hinderance than a boon as jump points become more frequent.
>
> It might be better to design it to be a graph structure from the
> beginning.
>
> -Paul Speed
>
> Jonathan Asbell wrote:
> >
> > Since my needs are for web container persistence, let me make a
suggestion
> > in that area.
> > An object called WorkflowPath could be created with configurable values
> > sucked up from a file. The values could be some kind of tree, like a
> > decision/process tree. The WorkflowPath object would be stored in
> > application scope, or a custom scope as mentioned below in the original
> > post, such as Sub-Application scope. When you begin a process you grab
the
> > WorkflowPath from the scope stored under a name like "loginWorkflow",
and
> > you would query it for the next step in the decision/process tree. It
would
> > be nice maybe to have a pointer as to where you are in the sequence of
> > things. Anyone want to add to this? Anyone want to dis this? Are you
all
> > asleep on this warm New York Summer night? =)
> >
> > ----- Original Message -----
> > From: "Geir Magnusson Jr." <ge...@optonline.net>
> > To: <st...@jakarta.apache.org>
> > Sent: Wednesday, June 20, 2001 11:25 PM
> > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> >
> > > Jonathan Asbell wrote:
> > > >
> > > > Persistent storage is an option too. I was hoping, however to limit
> > calls
> > > > through the enterprise parts and database.
> > >
> > > Why?
> > >
> > > > You could argue that it belongs
> > > > there because the database is the central location holding all data
and
> > > > information and therefore should hold workflow info, especially in
the
> > face
> > > > of changing services/activities. However, must I consult the
database
> > or a
> > > > db developer each time I want to add, change, or see anything? That
is
> > a
> > > > time waster.
> > >
> > > Not really. I mean, I guess it's your design requirements. I would
> > > want it to be that a user in a process (or a process itself) has no
> > > requirement of 'immediate completion' - i.e. some part of the flow can
> > > take a while.
> > >
> > > So then if the servlet container goes down, I don't care. No state
> > > lost.
> > >
> > > >
> > > > If you were not going to use persistent storage, how would you do
it?
> > >
> > > For what I want to do, i can't really escape it. Somewhere, something
> > > has to remember the state - assume the servlet container is going down
> > > at some point...
> > >
> > > geir
> > >
> > > > ----- Original Message -----
> > > > From: "Geir Magnusson Jr." <ge...@optonline.net>
> > > > To: <st...@jakarta.apache.org>
> > > > Sent: Wednesday, June 20, 2001 10:17 PM
> > > > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> > > >
> > > > > Can I ask why you don't go with persistant storage, like a rdbms?
I
> > > > > have been thinking about workflow recently as well, although not
> > > > > specifically w/in struts, and I believe that for the general
solution,
> > > > > where someone can come back a long time later and resume, or be it
an
> > > > > automated process, persistant storage would be required.
> > > > >
> > > > > geir
> > > > >
> > > > >
> > > > > > Jonathan Asbell wrote:
> > > > > >
> > > > > > 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).
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Geir Magnusson Jr. geirm@optonline.net
> > > > > System and Software Consulting
> > > > > Developing for the web? See http://jakarta.apache.org/velocity/
> > > > > You have a genius for suggesting things I've come a cropper with!
> > > > >
> > >
> > > --
> > > Geir Magnusson Jr. geirm@optonline.net
> > > System and Software Consulting
> > > Developing for the web? See http://jakarta.apache.org/velocity/
> > > You have a genius for suggesting things I've come a cropper with!
> > >
>
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Paul Speed <Pa...@metrixpoint.com>.
Just one small point...
In all my (admittedly brief compared to some) travels through workflow
land, I've never had a workflow that was specifically tree. They all
end up forming a graph at some point.
One could argue that you can just have jump points from one branch to
another, but in my experience, after many iterations the tree becomes
more of a hinderance than a boon as jump points become more frequent.
It might be better to design it to be a graph structure from the
beginning.
-Paul Speed
Jonathan Asbell wrote:
>
> Since my needs are for web container persistence, let me make a suggestion
> in that area.
> An object called WorkflowPath could be created with configurable values
> sucked up from a file. The values could be some kind of tree, like a
> decision/process tree. The WorkflowPath object would be stored in
> application scope, or a custom scope as mentioned below in the original
> post, such as Sub-Application scope. When you begin a process you grab the
> WorkflowPath from the scope stored under a name like "loginWorkflow", and
> you would query it for the next step in the decision/process tree. It would
> be nice maybe to have a pointer as to where you are in the sequence of
> things. Anyone want to add to this? Anyone want to dis this? Are you all
> asleep on this warm New York Summer night? =)
>
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, June 20, 2001 11:25 PM
> Subject: Re: Opening up a thread on ALTERNATE SCOPES
>
> > Jonathan Asbell wrote:
> > >
> > > Persistent storage is an option too. I was hoping, however to limit
> calls
> > > through the enterprise parts and database.
> >
> > Why?
> >
> > > You could argue that it belongs
> > > there because the database is the central location holding all data and
> > > information and therefore should hold workflow info, especially in the
> face
> > > of changing services/activities. However, must I consult the database
> or a
> > > db developer each time I want to add, change, or see anything? That is
> a
> > > time waster.
> >
> > Not really. I mean, I guess it's your design requirements. I would
> > want it to be that a user in a process (or a process itself) has no
> > requirement of 'immediate completion' - i.e. some part of the flow can
> > take a while.
> >
> > So then if the servlet container goes down, I don't care. No state
> > lost.
> >
> > >
> > > If you were not going to use persistent storage, how would you do it?
> >
> > For what I want to do, i can't really escape it. Somewhere, something
> > has to remember the state - assume the servlet container is going down
> > at some point...
> >
> > geir
> >
> > > ----- Original Message -----
> > > From: "Geir Magnusson Jr." <ge...@optonline.net>
> > > To: <st...@jakarta.apache.org>
> > > Sent: Wednesday, June 20, 2001 10:17 PM
> > > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> > >
> > > > Can I ask why you don't go with persistant storage, like a rdbms? I
> > > > have been thinking about workflow recently as well, although not
> > > > specifically w/in struts, and I believe that for the general solution,
> > > > where someone can come back a long time later and resume, or be it an
> > > > automated process, persistant storage would be required.
> > > >
> > > > geir
> > > >
> > > >
> > > > > Jonathan Asbell wrote:
> > > > >
> > > > > 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).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Geir Magnusson Jr. geirm@optonline.net
> > > > System and Software Consulting
> > > > Developing for the web? See http://jakarta.apache.org/velocity/
> > > > You have a genius for suggesting things I've come a cropper with!
> > > >
> >
> > --
> > Geir Magnusson Jr. geirm@optonline.net
> > System and Software Consulting
> > Developing for the web? See http://jakarta.apache.org/velocity/
> > You have a genius for suggesting things I've come a cropper with!
> >
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Jonathan Asbell <ja...@i-2000.com>.
Since my needs are for web container persistence, let me make a suggestion
in that area.
An object called WorkflowPath could be created with configurable values
sucked up from a file. The values could be some kind of tree, like a
decision/process tree. The WorkflowPath object would be stored in
application scope, or a custom scope as mentioned below in the original
post, such as Sub-Application scope. When you begin a process you grab the
WorkflowPath from the scope stored under a name like "loginWorkflow", and
you would query it for the next step in the decision/process tree. It would
be nice maybe to have a pointer as to where you are in the sequence of
things. Anyone want to add to this? Anyone want to dis this? Are you all
asleep on this warm New York Summer night? =)
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: <st...@jakarta.apache.org>
Sent: Wednesday, June 20, 2001 11:25 PM
Subject: Re: Opening up a thread on ALTERNATE SCOPES
> Jonathan Asbell wrote:
> >
> > Persistent storage is an option too. I was hoping, however to limit
calls
> > through the enterprise parts and database.
>
> Why?
>
> > You could argue that it belongs
> > there because the database is the central location holding all data and
> > information and therefore should hold workflow info, especially in the
face
> > of changing services/activities. However, must I consult the database
or a
> > db developer each time I want to add, change, or see anything? That is
a
> > time waster.
>
> Not really. I mean, I guess it's your design requirements. I would
> want it to be that a user in a process (or a process itself) has no
> requirement of 'immediate completion' - i.e. some part of the flow can
> take a while.
>
> So then if the servlet container goes down, I don't care. No state
> lost.
>
> >
> > If you were not going to use persistent storage, how would you do it?
>
> For what I want to do, i can't really escape it. Somewhere, something
> has to remember the state - assume the servlet container is going down
> at some point...
>
> geir
>
> > ----- Original Message -----
> > From: "Geir Magnusson Jr." <ge...@optonline.net>
> > To: <st...@jakarta.apache.org>
> > Sent: Wednesday, June 20, 2001 10:17 PM
> > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> >
> > > Can I ask why you don't go with persistant storage, like a rdbms? I
> > > have been thinking about workflow recently as well, although not
> > > specifically w/in struts, and I believe that for the general solution,
> > > where someone can come back a long time later and resume, or be it an
> > > automated process, persistant storage would be required.
> > >
> > > geir
> > >
> > >
> > > > Jonathan Asbell wrote:
> > > >
> > > > 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).
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Geir Magnusson Jr. geirm@optonline.net
> > > System and Software Consulting
> > > Developing for the web? See http://jakarta.apache.org/velocity/
> > > You have a genius for suggesting things I've come a cropper with!
> > >
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Developing for the web? See http://jakarta.apache.org/velocity/
> You have a genius for suggesting things I've come a cropper with!
>
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Jonathan Asbell <ja...@i-2000.com>.
Thats fine. You would like the state of the workflow saved in spite of a
server failure. The truth is we should figure out both situations anyway
for both types of requirements:
1) storing state in a database
2) storing state in the web container
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: <st...@jakarta.apache.org>
Sent: Wednesday, June 20, 2001 11:25 PM
Subject: Re: Opening up a thread on ALTERNATE SCOPES
> Jonathan Asbell wrote:
> >
> > Persistent storage is an option too. I was hoping, however to limit
calls
> > through the enterprise parts and database.
>
> Why?
>
> > You could argue that it belongs
> > there because the database is the central location holding all data and
> > information and therefore should hold workflow info, especially in the
face
> > of changing services/activities. However, must I consult the database
or a
> > db developer each time I want to add, change, or see anything? That is
a
> > time waster.
>
> Not really. I mean, I guess it's your design requirements. I would
> want it to be that a user in a process (or a process itself) has no
> requirement of 'immediate completion' - i.e. some part of the flow can
> take a while.
>
> So then if the servlet container goes down, I don't care. No state
> lost.
>
> >
> > If you were not going to use persistent storage, how would you do it?
>
> For what I want to do, i can't really escape it. Somewhere, something
> has to remember the state - assume the servlet container is going down
> at some point...
>
> geir
>
> > ----- Original Message -----
> > From: "Geir Magnusson Jr." <ge...@optonline.net>
> > To: <st...@jakarta.apache.org>
> > Sent: Wednesday, June 20, 2001 10:17 PM
> > Subject: Re: Opening up a thread on ALTERNATE SCOPES
> >
> > > Can I ask why you don't go with persistant storage, like a rdbms? I
> > > have been thinking about workflow recently as well, although not
> > > specifically w/in struts, and I believe that for the general solution,
> > > where someone can come back a long time later and resume, or be it an
> > > automated process, persistant storage would be required.
> > >
> > > geir
> > >
> > >
> > > > Jonathan Asbell wrote:
> > > >
> > > > 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).
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Geir Magnusson Jr. geirm@optonline.net
> > > System and Software Consulting
> > > Developing for the web? See http://jakarta.apache.org/velocity/
> > > You have a genius for suggesting things I've come a cropper with!
> > >
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Developing for the web? See http://jakarta.apache.org/velocity/
> You have a genius for suggesting things I've come a cropper with!
>
Re: Opening up a thread on ALTERNATE SCOPES
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jonathan Asbell wrote:
>
> Persistent storage is an option too. I was hoping, however to limit calls
> through the enterprise parts and database.
Why?
> You could argue that it belongs
> there because the database is the central location holding all data and
> information and therefore should hold workflow info, especially in the face
> of changing services/activities. However, must I consult the database or a
> db developer each time I want to add, change, or see anything? That is a
> time waster.
Not really. I mean, I guess it's your design requirements. I would
want it to be that a user in a process (or a process itself) has no
requirement of 'immediate completion' - i.e. some part of the flow can
take a while.
So then if the servlet container goes down, I don't care. No state
lost.
>
> If you were not going to use persistent storage, how would you do it?
For what I want to do, i can't really escape it. Somewhere, something
has to remember the state - assume the servlet container is going down
at some point...
geir
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, June 20, 2001 10:17 PM
> Subject: Re: Opening up a thread on ALTERNATE SCOPES
>
> > Can I ask why you don't go with persistant storage, like a rdbms? I
> > have been thinking about workflow recently as well, although not
> > specifically w/in struts, and I believe that for the general solution,
> > where someone can come back a long time later and resume, or be it an
> > automated process, persistant storage would be required.
> >
> > geir
> >
> >
> > > Jonathan Asbell wrote:
> > >
> > > 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).
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Geir Magnusson Jr. geirm@optonline.net
> > System and Software Consulting
> > Developing for the web? See http://jakarta.apache.org/velocity/
> > You have a genius for suggesting things I've come a cropper with!
> >
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Jonathan Asbell <ja...@i-2000.com>.
Persistent storage is an option too. I was hoping, however to limit calls
through the enterprise parts and database. You could argue that it belongs
there because the database is the central location holding all data and
information and therefore should hold workflow info, especially in the face
of changing services/activities. However, must I consult the database or a
db developer each time I want to add, change, or see anything? That is a
time waster.
If you were not going to use persistent storage, how would you do it?
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: <st...@jakarta.apache.org>
Sent: Wednesday, June 20, 2001 10:17 PM
Subject: Re: Opening up a thread on ALTERNATE SCOPES
> Can I ask why you don't go with persistant storage, like a rdbms? I
> have been thinking about workflow recently as well, although not
> specifically w/in struts, and I believe that for the general solution,
> where someone can come back a long time later and resume, or be it an
> automated process, persistant storage would be required.
>
> geir
>
>
> > Jonathan Asbell wrote:
> >
> > 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).
> >
> >
> >
> >
> >
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Developing for the web? See http://jakarta.apache.org/velocity/
> You have a genius for suggesting things I've come a cropper with!
>
Re: Opening up a thread on ALTERNATE SCOPES
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Can I ask why you don't go with persistant storage, like a rdbms? I
have been thinking about workflow recently as well, although not
specifically w/in struts, and I believe that for the general solution,
where someone can come back a long time later and resume, or be it an
automated process, persistant storage would be required.
geir
> Jonathan Asbell wrote:
>
> 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).
>
>
>
>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Ted Husted <hu...@apache.org>.
Currently, I'm just running everything in session scope, and attached
some convenience methods to an Action superclass, along the lines of the
saveErrors() convenience method. The cache is instantiated when the
actor logs in, and the convenience methods access it through a constant
key, just as Struts components access resources from the application
context under a known key.
Of course, you could also put one of these in application scope if
needed, and use it the way Struts uses the ActionMappings.
For a sub-application, or "package" scope, you could name the keys with
a dotted syntax (thisPakage.token or thatPackage.token), or add a
wrapper to place the objects in a bean with a "scope" property, and
define a hierachry (page/request/workflow/package/application). So, you
might request eiher (scope,token) or (token) if you just wanted the
lowest instance in the hierarchy.
In practice, the signature I'm using now includes the httpRequest, which
can be used to obtain the session.
In the action, the calls resolve to things like
// -- Check cache for form in progress
cacheRemoveForm(mapping,form,request,errors);
and
// -- Notify cache of latest key value
cacheSetString(request,"donor",thisForm.getDonor());
The cacheRemoveForm method uses BeanUtil.populate(), and so needs the
errors collection to report the exception if something shoudl go wrong
there.
Here's the Action code:
/**
* Store an ActionForm in the cache under it's mapping form name.
*
* @param mapping The ActionMapping used to select this instance
* @param actionForm The ActionForm bean for this request
* @param request The HTTP request we are processing
*/
protected void cachePutForm(ActionMapping mapping,
ActionForm form,
HttpServletRequest request) {
// Acquire cache
HttpSession session = request.getSession();
ResourceCache cache = (ResourceCache)
session.getAttribute(Constants.RESOURCE_CACHE_KEY);
if (cache!=null) {
// Store form under mapping name
servlet.log("cache: Saving Form",2);
// Tempted to clone this first, but shouldn't be necessary.
cache.put(mapping.getName(),form);
}
}
/**
* Remove a cached ActionForm, if it exists, and populate the given
* form.
*
* Reports an "unexpected" error if BeanUtil generates an exception.
*
* @param mapping The ActionMapping used to select this instance
* @param actionForm The ActionForm bean for this request
* @param request The HTTP request we are processing
* @param errors The ActionErrors resource
*/
protected void cacheRemoveForm(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
ActionErrors errors) {
// Acquire cache
HttpSession session = request.getSession();
ResourceCache cache = (ResourceCache)
session.getAttribute(Constants.RESOURCE_CACHE_KEY);
if (cache!=null) {
// Check for form
String formName = mapping.getName();
if (cache.containsKey(formName)) {
servlet.log("reg: Restoring Form from Registry",2);
ActionFormCache cachedForm = (ActionFormCache)
cache.remove(formName);
try {
BeanUtils.populate(form,cachedForm.getMap());
}
catch (IllegalAccessException iae) {
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError("action.error.unexpected"));
}
catch (InvocationTargetException ite) {
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError("action.error.unexpected"));
}
}
ActionFormCache thisForm = (ActionFormCache) form;
thisForm.resetKeys(mapping,request);
}
}
protected void cacheRemove(HttpServletRequest request, String key) {
// Acquire cache
HttpSession session = request.getSession();
ResourceCache cache = (ResourceCache)
session.getAttribute(Constants.RESOURCE_CACHE_KEY);
if (cache!=null) cache.remove(key);
}
protected void cacheSetString(HttpServletRequest request, String
key,
String value) {
if ((key!=null) && (value!=null)) {
// Acquire cache
HttpSession session = request.getSession();
ResourceCache cache = (ResourceCache)
session.getAttribute(Constants.RESOURCE_CACHE_KEY);
if (cache!=null) cache.put(new String(key),new
String(value));
}
}
Right now, the ResourceCache class is just a wrapper around a hashtable.
The ActionFormCache is an interface:
/**
* Define methods required to put and remove an
* Action Form to a hashtable or other resource.
*
* @author Ted Husted
* @version $Revision: 1.1 $ $Date: 2001/06/13 $
*/
public interface ActionFormCache {
// --------------------------------------------------- Instance
Variables
// -----------------------------------------------------------
Properties
// --------------------------------------------------------- Public
Methods
/**
* Reset only selected (key) fields in ActionForm, for use after
* removing ActionForm from a resource.
*/
public void resetKeys(ActionMapping mapping,
HttpServletRequest request);
/**
* Return map of properties, for use with BeanUtil.populate().
*
* @return map of properties, for use with BeanUtil.populate().
*/
public Map getMap();
}
Jonathan Asbell wrote:
>
> How are you dealing with scope.
>
> Do you use an adaptor to Session or ServletContext to hide the scope's
> implementation from the
> developer, or do you outright use a Session etc.
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Jonathan Asbell <ja...@i-2000.com>.
How are you dealing with scope.
Do you use an adaptor to Session or ServletContext to hide the scope's
implementation from the
developer, or do you outright use a Session etc.
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Thursday, June 21, 2001 6:33 AM
Subject: Re: Opening up a thread on ALTERNATE SCOPES
> What I'm working on myself right now is a "ResourceCache" where I can
> tuck things (like partially complete ActionForms) for future use. It's
> just a hashtable right now, but the objects could also be wrapped if
> additional properties were needed.
>
> I'm using it to do two things: (1) save partially completed ActionForms
> for later use, and (2) save the current key values from ActionForms for
> use on other forms. The idea being I can detour in the middle of
> completing a form (save it to the cache), look something up on another
> form (save the key to the cache), and go back and complete the form (pop
> from the cache (restore and dispose), update key values from cache).
>
> I also started thinking of it as a cache, since if heavily used it might
> need to be capped, so that older items were automatically disposed when
> it was "full".
>
> <OT>
>
> Here's a wild idea that came up whilst explaining Struts to another
> developer:
>
> How about scoped ActionMappings that pertain to a particular user,
> perhaps loaded as part of a customization?
>
> </OT>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
> > Jonathan Asbell wrote:
> >
> > 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).
>
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Jonathan Asbell <ja...@i-2000.com>.
you are an early bird ted!
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Thursday, June 21, 2001 7:31 AM
Subject: Re: Opening up a thread on ALTERNATE SCOPES
> Sorry, I should have said remove rather than pop. It's a hashtable, so
> everything is accessed by a token name.
>
> Jonathan Asbell wrote:
> > If you are pushing and popping how do you get to the bottom ones anyway?
>
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Ted Husted <hu...@apache.org>.
Sorry, I should have said remove rather than pop. It's a hashtable, so
everything is accessed by a token name.
Jonathan Asbell wrote:
> If you are pushing and popping how do you get to the bottom ones anyway?
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Jonathan Asbell <ja...@i-2000.com>.
Ted, can you explain a little more about:
"I also started thinking of it as a cache, since if heavily used it might
need to be capped, so that older items were automatically disposed when it
was 'full'. "
If you are pushing and popping how do you get to the bottom ones anyway?
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Thursday, June 21, 2001 6:33 AM
Subject: Re: Opening up a thread on ALTERNATE SCOPES
> What I'm working on myself right now is a "ResourceCache" where I can
> tuck things (like partially complete ActionForms) for future use. It's
> just a hashtable right now, but the objects could also be wrapped if
> additional properties were needed.
>
> I'm using it to do two things: (1) save partially completed ActionForms
> for later use, and (2) save the current key values from ActionForms for
> use on other forms. The idea being I can detour in the middle of
> completing a form (save it to the cache), look something up on another
> form (save the key to the cache), and go back and complete the form (pop
> from the cache (restore and dispose), update key values from cache).
>
> I also started thinking of it as a cache, since if heavily used it might
> need to be capped, so that older items were automatically disposed when
> it was "full".
>
> <OT>
>
> Here's a wild idea that came up whilst explaining Struts to another
> developer:
>
> How about scoped ActionMappings that pertain to a particular user,
> perhaps loaded as part of a customization?
>
> </OT>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
> > Jonathan Asbell wrote:
> >
> > 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).
>
Re: Opening up a thread on ALTERNATE SCOPES
Posted by Ted Husted <hu...@apache.org>.
What I'm working on myself right now is a "ResourceCache" where I can
tuck things (like partially complete ActionForms) for future use. It's
just a hashtable right now, but the objects could also be wrapped if
additional properties were needed.
I'm using it to do two things: (1) save partially completed ActionForms
for later use, and (2) save the current key values from ActionForms for
use on other forms. The idea being I can detour in the middle of
completing a form (save it to the cache), look something up on another
form (save the key to the cache), and go back and complete the form (pop
from the cache (restore and dispose), update key values from cache).
I also started thinking of it as a cache, since if heavily used it might
need to be capped, so that older items were automatically disposed when
it was "full".
<OT>
Here's a wild idea that came up whilst explaining Struts to another
developer:
How about scoped ActionMappings that pertain to a particular user,
perhaps loaded as part of a customization?
</OT>
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
> Jonathan Asbell wrote:
>
> 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).