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).
