You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Oleg V Alexeev <go...@penza.net> on 2001/07/01 22:25:51 UTC
About extensons support mechanism...
Hello struts-dev,
This evening I end up druft of ServicesServlet - extended version of
ActionServlet with support of pluggable services (extensions in old
terms). I puzzle over architectural question about ServicesServlet
and may be anybody can suggest me right way...
ServiceServlet work on idea - developer can register unlimited
number of services in struts-config, each service is a java class
based on Service interface, each service can be subscribed to any
processing point, such as - init, destroy, initDigester,
processPreprocess, processPopulateBefore, processPopulateAfter,
processValidateBefore, processValidateAfter. ServiceServlet iterate
via list of subscriptions at every processing point and call
appropriate method from service.
My question is - what way is the best to serve processing points
listed above? Now I create FastArrayList instances for every
subscription list and all manipulations with subscriptions
(register, get iterator via subscriptions, drop, etc.) are made with
help of separate method -
registerInitMember( Service service, int order ) {}
regisetrInitDigesterMember( Service service, int order ) {}
....
May be such solution would be more flexible? -
registerMember( Service service, int order, String pointName ) {
//find ArrayList of subscriptions for such pointName
//register service at ArrayList
}
Hard coded solution is more reliable, but time consume and not
flexible. But more flexible solution, with search for appropriate
subscription, is slow for my mind. What way is the best?
--
Best regards,
Oleg mailto:gonza@penza.net
Re[2]: About extensons support mechanism...
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Martin,
Sunday, July 08, 2001, 4:55:56 AM, you wrote:
>> Is what I describe above within the scope of the event/listener
>> todo for 1.1? I thought it might be, which is why I said
>> I was interested in tying the Extensions package into
>> the event/listener model work.
MC> I think this is a perfect candidate for the event/listener framework. The
MC> key is to decide what the interesting events are. This needs to be done
MC> outside the context of the current implementation as much as possible.
MC> What I mean by that is that we should not be looking at the code and saying
MC> "oh, there's an interesting method I'd like to hook into" so much as
MC> thinking "ah, it would be interesting to be told when this is about to
MC> happen or that has finished happening". If the code ends up needing some
MC> restructuring to accommodate that, then we should go ahead and make those
MC> changes.
MC> If we only look at the current implementation, then we will be looking with
MC> blinders on. There is a much greater risk that we will hinder the
MC> development of later extensions, by looking at what we have instead of
MC> thinking about what we really want.
Yes. Now I try implement first edition of such ServicesServlet in base
of ActionServlet code and insert calls to the Services to the main
(for my mind) processing points. I not venture to make core
refactoring of ActionServlet - I only insert calls to the external
services to the processPreprocess(), processValidate(), etc.
MC> --
MC> Martin Cooper
MC> ----- Original Message -----
MC> From: "Ron Smith" <ro...@rpsenterprises.com>
MC> To: <st...@jakarta.apache.org>
MC> Sent: Wednesday, July 04, 2001 6:18 AM
MC> Subject: Re: About extensons support mechanism...
>>
>> When I created the ExtensionsServlet (I assume ServicesServlet
>> takes its place here), I stopped short after the
>> init(), destroy(), and initDigester() methods because I had
>> a feeling that we might want to handle extending the other
>> methods using a different mechanism.
>> I see init, destroy, and initDigester methods as basic
>> lifecycle methods that most/all extensions/services would want
>> to tap into.
>> When getting into the process() type of methods, I could see
>> many extensions would want to tap into one or more of these methods,
>> but why limit it to the ActionServlet class? An extension may want
>> to be able to tap into points in processing of other classes, such
>> as an action class or forward class. From looking at the code it seems
>> like most processing is going on in the ActionServlet, but
>> my gut feel is that some extensions will need to extend processing
>> points in other classes besides ActionServlet - it's just one class
>> in an application framework after all.
>>
>> For this, I think something like your second solution with a more
>> centralized event dispatcher/queue would be needed. The listeners
>> (services) would register interest in an event with a central
>> dispatcher. When the ActionServlet (or whatever class is generating
>> the events) gets to one of these points in processing, like
>> processPopulateBefore(), it would fire off an event to the central
>> dispatcher which would immediately notify the listeners registered
>> for that event type.
>> So the listeners are decoupled from the class generating the
>> events (e.g. ActionServlet). Heck, the object generating the
>> event doesn't even have to exist for the listener to be able to
>> register interest in the event it generates (which is probably necessary
>> to trap events from classes like Action and ActionForward).
>>
>> Is what I describe above within the scope of the event/listener
>> todo for 1.1? I thought it might be, which is why I said
>> I was interested in tying the Extensions package into
>> the event/listener model work.
>>
>> So my two cents is I'd like to generalize the listener/event/dispatch
>> mechanism and to support listening to classes beyond ActionServlet.
>>
>>
>> Oleg V Alexeev wrote:
>> >
>> > Hello struts-dev,
>> >
>> > This evening I end up druft of ServicesServlet - extended version of
>> > ActionServlet with support of pluggable services (extensions in old
>> > terms). I puzzle over architectural question about ServicesServlet
>> > and may be anybody can suggest me right way...
>> >
>> > ServiceServlet work on idea - developer can register unlimited
>> > number of services in struts-config, each service is a java class
>> > based on Service interface, each service can be subscribed to any
>> > processing point, such as - init, destroy, initDigester,
>> > processPreprocess, processPopulateBefore, processPopulateAfter,
>> > processValidateBefore, processValidateAfter. ServiceServlet iterate
>> > via list of subscriptions at every processing point and call
>> > appropriate method from service.
>> >
>> > My question is - what way is the best to serve processing points
>> > listed above? Now I create FastArrayList instances for every
>> > subscription list and all manipulations with subscriptions
>> > (register, get iterator via subscriptions, drop, etc.) are made with
>> > help of separate method -
>> >
>> > registerInitMember( Service service, int order ) {}
>> > regisetrInitDigesterMember( Service service, int order ) {}
>> > ....
>> >
>> > May be such solution would be more flexible? -
>> > registerMember( Service service, int order, String pointName ) {
>> > //find ArrayList of subscriptions for such pointName
>> > //register service at ArrayList
>> > }
>> >
>> > Hard coded solution is more reliable, but time consume and not
>> > flexible. But more flexible solution, with search for appropriate
>> > subscription, is slow for my mind. What way is the best?
>> >
>> >
>> > --
>> > Best regards,
>> > Oleg mailto:gonza@penza.net
>>
--
Best regards,
Oleg mailto:gonza@penza.net
Re: About extensons support mechanism...
Posted by Ron Smith <ro...@rpsenterprises.com>.
"Craig R. McClanahan" wrote:
>
> One fairly radical idea I've considered is to not use events for this
> purpose, but to treat the basic processing that the controller servlet
> itself does as a workflow that can be scripted. That way, you could (in
> effect) insert your own "processXxxx" type functions anyplace you like in
> the standard workflow. Presumably, the scripting language for the
> workflow would have mechanisms to support conditional processing to deal
> with my question above.
>
> Craig
Very interesting. I don't have much background with workflows,
but what you describe sounds like a high level scripting
language that could be invoked from the servlet or any class,
possibly coded in XML. Each Struts extension could add script
fragments to particular workflows. The script fragments could
express things like conditionals, calling methods on objects, and
would be able to do things like discontinue the current workflow.
As you point out, doing things like changing the flow of execution
(e.g. taking user to login) are difficult and/or messy using
an event/listener mechanism.
When you mention treating the basic processing of the servlet as a
workflow, what level are you talking about? Would a substantial
amount of the servlet processing be coded as a workflow (e.g.
replace existing servlet java code with workflow script) or would
most of the servlet java code remain, and the servlet would just look up
and
invoke workflows at particular points in processing (like
validation, request processing, forwarding, etc...).
I took a look at IBM's bean scripting framework and bean markup
language (BML) thinking they might be something that could be
leveraged. They sounded promising but unfortunately it looks
like BML isn't open source.
An opbervation:
This seems to be on a different level than the other
Workflows discussion that's going on. This sounds to me like
internal servlet workflows, while the other workflows are
more geared towards interactions between the end user and
the overall web application (e.g. user must go through
credit card entry screen before finally submitting order).
--Ron S
Re[2]: About extensons support mechanism...
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Craig,
Sunday, July 08, 2001, 5:09:42 AM, you wrote:
CRM> On Sat, 7 Jul 2001, Martin Cooper wrote:
>> > Is what I describe above within the scope of the event/listener
>> > todo for 1.1? I thought it might be, which is why I said
>> > I was interested in tying the Extensions package into
>> > the event/listener model work.
>>
>> I think this is a perfect candidate for the event/listener framework. The
>> key is to decide what the interesting events are. This needs to be done
>> outside the context of the current implementation as much as possible.
>>
CRM> I think the two concepts are related as well. "Extensions" would be a
CRM> perfectly natural way to configure your listeners.
>> What I mean by that is that we should not be looking at the code and saying
>> "oh, there's an interesting method I'd like to hook into" so much as
>> thinking "ah, it would be interesting to be told when this is about to
>> happen or that has finished happening". If the code ends up needing some
>> restructuring to accommodate that, then we should go ahead and make those
>> changes.
>>
>> If we only look at the current implementation, then we will be looking with
>> blinders on. There is a much greater risk that we will hinder the
>> development of later extensions, by looking at what we have instead of
>> thinking about what we really want.
>>
CRM> Another issue (and, frankly, the reason that I didn't include an
CRM> event/listener model earlier) is more complex -- what if a listener wants
CRM> to *modify* what happens next? For example, let's say you wanted to
CRM> implement "is the user logged on?" checking as an event listener. How
CRM> would the listener indicate back to the framework that the request should
CRM> be redirected to the logon page?
I think it must be defined in ActionServlet code. Call to the external
service can return result and ActionServlet make solution on base of
it. And more - service method itself can take request object, do
redirect to the logon page and return false as for processPreprocess.
CRM> One fairly radical idea I've considered is to not use events for this
CRM> purpose, but to treat the basic processing that the controller servlet
CRM> itself does as a workflow that can be scripted. That way, you could (in
CRM> effect) insert your own "processXxxx" type functions anyplace you like in
CRM> the standard workflow. Presumably, the scripting language for the
CRM> workflow would have mechanisms to support conditional processing to deal
CRM> with my question above.
Great! But in first iteration I want to lay the foundation of
ServicesManager. But now another idea worry my mind... 8) All logic of
ActionServlet can be build on base of Services approach... With
scripting, workflow support, etc. I agree with you.
CRM> Given that, an event/listener model that merely notifies application logic
CRM> about things that are happening is still useful -- it's just not going to
CRM> be called on to serve this purpose.
--
Best regards,
Oleg mailto:gonza@penza.net
Re: About extensons support mechanism...
Posted by Roland Huss <Ro...@consol.de>.
"Craig R. McClanahan" <cr...@apache.org> writes:
> In Struts 1.0, you could implement this by extending ActionServlet and
> override, say, processActionPerform() to add your check. That's certainly
> feasible, but it requires an understanding of the internals of
> ActionServlet.
Or, you could extend Action in a BaseAction like
public ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
try
{
if (!isRuntimeValid(request))
{
return forwardToLogin(mapping,request);
}
return performAction(mapping,form,request,response);
}
catch (Exception exp)
{
Log.error("Exception in perform()",exp);
request.setAttribute(Parameter.EXCEPTION_REQ,exp);
return mapping.findForward("error-jsp");
}
}
and let your specific Action extend BaseAction and implement a
'performAction()' method.
--
...roland huss
consol.de
Re: About extensons support mechanism...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 8 Jul 2001, Jonathan Asbell wrote:
> Craig could you explain a little more about ........" to *modify* what
> happens next? For example, let's say you wanted to implement "is the user
> logged on?" checking as an event listener. How would the listener indicate
> back to the framework that the request should be redirected to the logon
> page?......"
>
> I dont understand the problem completely
>
Sure.
Typically (or at least from what I've seen), event listeners in Java are
notified about things that happen, but cannot directly affect the control
flow of what will happen next (with the possible exception of
VetoableChangeListener that allows a listener to "veto" a change to a
particular property). Notification is very useful, but it's not
sufficient to meet all the needs.
My example use case was a typical scenario where notification is
insufficient. Let's say we want to take advantage of the fact that all
requests flow through the controller, and implement "is the user currently
logged on" checking. If the user is *not* currently logged on, he or she
should be redirected to the login page, instead of executing the action
that would normally be executed.
In Struts 1.0, you could implement this by extending ActionServlet and
override, say, processActionPerform() to add your check. That's certainly
feasible, but it requires an understanding of the internals of
ActionServlet.
In the spirit of the "extensions" or "services framework" idea, we've been
talking about the idea of adding event listeners dynamically, based on
configuration information in struts-config.xml. That part is pretty
straightforward, but I still cannot use an event listener to implement the
"is the user currently logged on" check, because listeners cannot change
the control flow.
It seems to me that we want to look at the basic processing done by
ActionServlet for each request as a sort of "workflow" of prebuilt tasks,
and allow you to dynamically plug in extensions or services *anywhere* in
the flow. And, the configuration mechanism (or workflow script) needs to
support conditional logic so that a particular extension can say things
like "we are through processing this request now, so the rest of the
standard processing should be skipped".
I've been spending some airplane time writing down an approach to this --
it's almost ready to be proposed to STRUTS-DEV for consideration. It just
seems to me that, since we're considering some pretty radical surgery on
ActionServlet, that we should implement something more powerful than just
an event notification gadget.
Craig
Re: About extensons support mechanism...
Posted by Jonathan Asbell <ja...@i-2000.com>.
Craig could you explain a little more about ........" to *modify* what
happens next? For example, let's say you wanted to implement "is the user
logged on?" checking as an event listener. How would the listener indicate
back to the framework that the request should be redirected to the logon
page?......"
I dont understand the problem completely
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Saturday, July 07, 2001 9:09 PM
Subject: Re: About extensons support mechanism...
>
>
> On Sat, 7 Jul 2001, Martin Cooper wrote:
>
> > > Is what I describe above within the scope of the event/listener
> > > todo for 1.1? I thought it might be, which is why I said
> > > I was interested in tying the Extensions package into
> > > the event/listener model work.
> >
> > I think this is a perfect candidate for the event/listener framework.
The
> > key is to decide what the interesting events are. This needs to be done
> > outside the context of the current implementation as much as possible.
> >
>
> I think the two concepts are related as well. "Extensions" would be a
> perfectly natural way to configure your listeners.
>
> > What I mean by that is that we should not be looking at the code and
saying
> > "oh, there's an interesting method I'd like to hook into" so much as
> > thinking "ah, it would be interesting to be told when this is about to
> > happen or that has finished happening". If the code ends up needing some
> > restructuring to accommodate that, then we should go ahead and make
those
> > changes.
> >
> > If we only look at the current implementation, then we will be looking
with
> > blinders on. There is a much greater risk that we will hinder the
> > development of later extensions, by looking at what we have instead of
> > thinking about what we really want.
> >
>
> Another issue (and, frankly, the reason that I didn't include an
> event/listener model earlier) is more complex -- what if a listener wants
> to *modify* what happens next? For example, let's say you wanted to
> implement "is the user logged on?" checking as an event listener. How
> would the listener indicate back to the framework that the request should
> be redirected to the logon page?
>
> One fairly radical idea I've considered is to not use events for this
> purpose, but to treat the basic processing that the controller servlet
> itself does as a workflow that can be scripted. That way, you could (in
> effect) insert your own "processXxxx" type functions anyplace you like in
> the standard workflow. Presumably, the scripting language for the
> workflow would have mechanisms to support conditional processing to deal
> with my question above.
>
> Given that, an event/listener model that merely notifies application logic
> about things that are happening is still useful -- it's just not going to
> be called on to serve this purpose.
>
> > --
> > Martin Cooper
> >
>
> Craig
>
Re: ActionMapping Workflows
Posted by Matthias Bauer <Ma...@livinglogic.de>.
Ok,
then maybe we should start to work on that. The first step should be to define
the requirements, i. e. what do we expect from the workflow implementation is
struts?
My requirements would be the following (part 1 and 2 I already implemented):
1. Define which actions can follow the current action.
2. Define which actions are allowed to be executed immediately before the
current action.
3. A stack with actions to which to return, if some branched action path is
finished.
4. Your requirement, Ted, to allow configuration of form action parameters via
struts-config.xml
What about setting up a new thread with a request for required features?
--- Matthias
Ted Husted wrote:
> A few people were working on diagramming workflows, but didn't seem to
> be working on actually implementating workflows in Struts.
>
> There's been a lot of hand-waving discussions as to workflows on the
> list, but nothing concrete.
>
> The committers do not work together outside the DEV list, so anything
> that's being done is being done here.
>
> I agree there should be a reasonable high concept. What are your
> thoughts here?
>
> Matthias Bauer wrote:
>
>>Ok, that's fine with me and it makes pretty much sense. However, this will not
>>be enough to implement workflow completely. It is just a little step toward
>>workflow control as a whole, just the same as the simple workflow extension I
>>already proposed together with some code on this list.
>>
>>I think all this should be put together to come up with a reasonable concept how
>>to implement workflow, instead of multiple single efforts to implement some
>>single aspects only.
>>
>>Is there a team working on that?
>>
>>--- Matthias
>>
Re: ActionMapping Workflows
Posted by Ted Husted <hu...@apache.org>.
A few people were working on diagramming workflows, but didn't seem to
be working on actually implementating workflows in Struts.
There's been a lot of hand-waving discussions as to workflows on the
list, but nothing concrete.
The committers do not work together outside the DEV list, so anything
that's being done is being done here.
I agree there should be a reasonable high concept. What are your
thoughts here?
Matthias Bauer wrote:
>
> Ok, that's fine with me and it makes pretty much sense. However, this will not
> be enough to implement workflow completely. It is just a little step toward
> workflow control as a whole, just the same as the simple workflow extension I
> already proposed together with some code on this list.
>
> I think all this should be put together to come up with a reasonable concept how
> to implement workflow, instead of multiple single efforts to implement some
> single aspects only.
>
> Is there a team working on that?
>
> --- Matthias
Re: ActionMapping Workflows
Posted by Nick Afshartous <ni...@proactcorp.com>.
Ted Husted writes:
...
> So, I would envision something like this for the ActionMappings
>
> <!-- This Action would be passed the path to the current workflow,
> if any. It would check for any pending ActionRequest (workflow
> already begun) and forward to that instead of "next" if present -->
>
> <action
> path="/workflow/registration"
> type="bbs.workflow.init"
> validate="false"
> parameter="registration">
> <forward
> name="next"
> path="/workflow/registration/account/Input"
> />
> </action>
>
> <action
> path="/workflow/registration/account/Input"
> type="bbs.account.http.Access"
> name="accountForm"
> validate="false"
> workflow="registration"
> parameter="input">
The first action I assume is an internal init action that
would go at the beginning of all workflows. How about instead
adding another action attribute to specify special workflow
states such as "init" and "end". This would preclude
the first action definition above.
<action
path="/workflow/registration/account/Input"
type="bbs.account.http.Access"
name="accountForm"
validate="false"
workflow="registration"
workflowState="init"
parameter="input">
In this way references to the internal workflow classes and
machinery would not exposed in struts-config.
--
Nick
Re: ActionMapping Workflows
Posted by Ted Husted <hu...@apache.org>.
OK, so our initial draft working requirements are
1. Define which actions can follow the current action.
2. Define which actions are allowed to be executed immediately before
the current action.
3. Define which action will follow the current action (dynamic action
path).
4. Invoke another workflow and return to the current state when
complete.
I believe the use case tests each of these points.
For what I have in mind, we really need some type of bookmark, like
Martin's ActionRequest. That way the framework can track the prior and
current action request for each session. Then the initial step of a
workflow could cache the prior ActionRequest, and return there when it
is complete.
Each step of the workflow could also cache it's own ActionRequest, to
allow an actor to wander off and then re-enter the workflow again later,
with their data intact.
Forms that rely on a foreign key from another table could also check the
cache to populate those properties. I'm doing this now and it makes
linking related forms very easy.
So, I would envision something like this for the ActionMappings
<!-- This Action would be passed the path to the current workflow,
if any. It would check for any pending ActionRequest (workflow
already begun) and forward to that instead of "next" if present -->
<action
path="/workflow/registration"
type="bbs.workflow.init"
validate="false"
parameter="registration">
<forward
name="next"
path="/workflow/registration/account/Input"
/>
</action>
<action
path="/workflow/registration/account/Input"
type="bbs.account.http.Access"
name="accountForm"
validate="false"
workflow="registration"
parameter="input">
<!-- Before forwarding to "next" each action would
set an ActionRequest record to itself when workflow!=null -->
<forward
name="next"
path="/WEB-INF/pages/account/Form.jsp"
submit="/workflow/registration/account/Insert"
/>
<forward
name="cancel"
path="/workflow/registeration/Release"
/>
</action>
<action
path="/workflow/registration/account/Insert"
type="bbs.account.http.Access"
name="contactForm"
validate="true"
input="/WEB-INF/pages/account/Form.jsp"
workflow="registration"
parameter="insert">
<forward
name="back"
path="/workflow/registration/account/Input"
/>
<forward
name="next"
path="/workflow/registration/contact/Input"
/>
<forward
name="cancel"
path="/workflow/registeration/Release"
/>
</action>
<action
path="/workflow/registration/contact/Input"
type="bbs.contact.http.Access"
name="contactForm"
validate="false"
workflow="registration"
parameter="input">
<forward
name="next"
path="/WEB-INF/pages/contact/Form.jsp"
submit="/workflow/registration/contact/Insert"
/>
<forward
name="cancel"
path="/workflow/registeration/Release"
/>
</action>
<action
path="/workflow/registration/contact/Insert"
type="bbs.contact.http.Access"
name="contactForm"
validate="true"
input="/WEB-INF/pages/contact/Form.jsp"
workflow="registration"
parameter="insert">
<forward
name="back"
path="/workflow/registration/contact/Input"
/>
<forward
name="next"
path="/workflow/registration/Validate"
/>
<forward
name="cancel"
path="/workflow/registeration/Release"
/>
</action>
<!-- This Action would review the steps of the workflow and
make sure everything was complete, and make any additional
updates needed to reflect that the workflow was successful.
-->
<action
path="/workflow/registration/Validate"
type="bbs.workflow.registration.validate"
validate="false"
workflow="registration" >
<forward
name="back"
path="/workflow/registration/"
/>
<forward
name="next"
path="/workflow/registration/Release"
/>
</action>
<!-- This Action would release any cached data. If another workflow was
registered at the beginning, it would forward there instead of the given
next -->
<action
path="/workflow/registration/Release"
type="bbs.workflow.release"
validate="false"
workflow="registration"
parameter="/workflow/registration/*" >
<forward
name="next"
path="/menu"
/>
<forward
name="prev"
path="/workflow/Invalid"
parameter="/workflow/registration"
/>
</action>
<!-- /workflow/Invalid would be a generic error page that would return
the Action to the beginning of the workflow to enter missing data -->
Matthias Bauer wrote:
>
> First of all: Sounds good to restate the requirement.
>
> Second: Maybe we can talk of some use cases here, in order to put some flesh to
> the workflow bones.
>
> How about considering the following really simple use case:
>
> Workflow1: The user browses in an open community board and is currently visiting
> Board xy and Thread yz. Now he wants to add a new comment to the thread. He
> needs a valid account for that. As he does not yet have an account, he decides
> to register himself. He ends up in starting Workflow2.
>
> Workflow2: The user steps through the registration process, entering his
> personal data and his desired username and password.
>
> After Workflow2 has been finished he needs to return to Workflow1, i. e exactly
> to the same position (Board xy and Thread yz) where he came from.
>
> I don't know if this use case is appropriate. If not, pls come up with a better
> or extended one. It surely is too trivial to cover all the aspects, but maybe it
> helps to clarify at least the basic streamlines.
>
> How do you all think the chain of action mappings should look like for this use
> case and what happens regarding to the stack everybody talks of?
>
> --- Matthias
Re: ActionMapping Workflows
Posted by Matthias Bauer <Ma...@livinglogic.de>.
First of all: Sounds good to restate the requirement.
Second: Maybe we can talk of some use cases here, in order to put some flesh to
the workflow bones.
How about considering the following really simple use case:
Workflow1: The user browses in an open community board and is currently visiting
Board xy and Thread yz. Now he wants to add a new comment to the thread. He
needs a valid account for that. As he does not yet have an account, he decides
to register himself. He ends up in starting Workflow2.
Workflow2: The user stept through the registration process, entering his
personal data and his desired username and password.
After Workflow2 has been finished he needs to return to Workflow1, i. e exactly
to the same position (Board xy and Thread yz) where he came from.
I don't know if this use case is appropriate. If not, pls come up with a better
or extended one. It surely is too trivial to cover all the aspects, but maybe it
helps to clarify at least the basic streamlines.
How do you all think the chain of action mappings should look like for this use
case and what happens regarding to the stack everybody talks of?
--- Matthias
Martin Cooper wrote:
> Right now, what I have is a combination of code fragments, pseudo-code, and
> stuff that's still in my head. I expect to turn this into real code in the
> next day or so.
>
> Point taken regarding not implying an implementation. I agree with your
> restatement of the real requirement. My near-term implementation may still
> be a stack, though. :-}
>
> --
> Martin Cooper
>
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Tuesday, July 10, 2001 2:16 PM
> Subject: Re: ActionMapping Workflows
>
>
>
>>I'm liking the ActionRequest idea. I've tried similar things, but needed
>>the parameter map idea.
>>
>>Do you have any code yet?
>>
>>I agree that leveraging ActionForwards sounds like the way to go.
>>
>>As to the requirements Matthias started, I would change 3 to
>>
>>3. The ability to call (or nest) another workflow and return to the
>>current step when the called workflow is complete.
>>
>>So as to not imply a particular implementation.
>>
>>Martin Cooper wrote:
>>
>>>I have a similar concern. In addition, there may be runtime parameter
>>>values that need to be passed along, particularly when actions are
>>>
> chained
>
>>>(something I do a lot of).
>>>
>>>I am working on something related, in conjunction with what Matthias
>>>referred to as a return stack. The goal is to be able to handle "go back
>>>
> to
>
>>>where you came from" requests, where the specification of the actual
>>>destination could require multiple dynamic parameters.
>>>
>>>The idea is that there is something called an ActionRequest, which is
>>>essentially a combination of an ActionForward and a parameter Map, with
>>>some "smarts" added in. A stack of these objects is kept in the session.
>>>When one is popped off the stack, the "smarts" will find the appropriate
>>>form bean type, populate one from the parameter map, forward the request
>>>
> as
>
>>>appropriate, and have Struts invoke the target action with this new form
>>>bean instead of the one it would normally get.
>>>
>>>I haven't fully figured this out yet, and there are some pieces of the
>>>puzzle I'm still working through. It's pretty clearly targetted at using
>>>forwards to chain actions, but it should be able to be extended to work
>>>with redirects, forwards to JSPs, etc.
>>>
>>>Thoughts, anyone?
>>>
>>>--
>>>Martin Cooper
>>>
>>>At 08:35 AM 7/10/01, Robbin L. Gratz wrote:
>>>
>>>
>>>>Another point that I believe is getting ignored on the workflow stuff
>>>>
> is how
>
>>>>is data getting transferred between the different steps. In the system
>>>>
> I
>
>>>>just worked on, we had a number of two or more step workflows that were
>>>>
> used
>
>>>>within other larger workflows. The output from these "sub workflows"
>>>>
> needed
>
>>>>to be captured along the way to accomplish the parent workflow. My
>>>>
> thought
>
>>>>was to have a controlling action whose associated data/form object
>>>>
> stores
>
>>>>the data retrieved from the various steps of a workflow, whether these
>>>>
> steps
>
>>>>were individual actions or another workflow process. Any thoughts from
>>>>anyone or has someone solved this issue more elegantly?
>>>>
>>>>-----Original Message-----
>>>>From: Jonathan [mailto:jasbell@i-2000.com]
>>>>Sent: Tuesday, July 10, 2001 8:35 AM
>>>>To: struts-dev@jakarta.apache.org; Matthias.Bauer@livinglogic.de
>>>>Subject: Re: ActionMapping Workflows
>>>>
>>>>
>>>>Can I ask how you all are thinking about bouncing around between steps
>>>>
> in
>
>>>>the workflow? Is it a stack that each step gets popped off? Arent
>>>>
> workflow
>
>>>>steps cyclical sometimes? Developers talk alot about graphing
>>>>
> workflows but
>
>>>>I have not read about the implementation.
>>>>
>>>>
>>>>----- Original Message -----
>>>>From: "Matthias Bauer" <Ma...@livinglogic.de>
>>>>To: <st...@jakarta.apache.org>
>>>>Sent: Tuesday, July 10, 2001 9:12 AM
>>>>Subject: Re: ActionMapping Workflows
>>>>
>>>>
>>>>
>>>>>Ok, that's fine with me and it makes pretty much sense. However,
>>>>>
> this will
>
>>>>not
>>>>
>>>>>be enough to implement workflow completely. It is just a little step
>>>>>
>>>>toward
>>>>
>>>>>workflow control as a whole, just the same as the simple workflow
>>>>>
>>>>extension I
>>>>
>>>>>already proposed together with some code on this list.
>>>>>
>>>>>I think all this should be put together to come up with a reasonable
>>>>>
>>>>concept how
>>>>
>>>>>to implement workflow, instead of multiple single efforts to
>>>>>
> implement
>
>>>>some
>>>>
>>>>>single aspects only.
>>>>>
>>>>>Is there a team working on that?
>>>>>
>>>>>--- Matthias
>>>>>
>>>>>
>>>>>
>>>>>Ted Husted wrote:
>>>>>
>>>>>
>>>>>>I suppose storing the information in the session would work.
>>>>>>
> Though, I
>
>>>>>>imagine this means the state value would be hardcoded into the
>>>>>>
> Java
>
>>>>>>source. I'm working toward scripting workflows from within the
>>>>>>ActionMappings, and would like to be able to reroute the flow
>>>>>>
> without
>
>>>>>>changing the Java source.
>>>>>>
>>>>>>The insert/update flow is one example. Another would be inserting
>>>>>>
> one
>
>>>>>>record and stopping, or inserting one record type and then another
>>>>>>
> type
>
>>>>>>(and another type). Like say, creating a new vendor account, and
>>>>>>
> then a
>
>>>>>>contact record for the account, and then a new stock item for the
>>>>>>account. With a dynamic action path, you can script something like
>>>>>>
> this
>
>>>>>>from the ActionMappings alone, without modifying the JSPs or Java
>>>>>>source.
>>>>>>
>>>>>>I'm also now thinking that, given a dynamic action path, the best
>>>>>>
> place
>
>>>>>>to represent it may be the ActionForward after all. This would
>>>>>>
> change
>
>>>>>>the struts-config in my last post to:
>>>>>>
>>>>>><action ...>
>>>>>> <forward
>>>>>> name="continue"
>>>>>> path="/WEB-INF/pages/script/Form.jsp"
>>>>>> request="true"
>>>>>> actionPath="/script/Insert"/>
>>>>>></action>
>>>>>>
>>>>>>which supports the idea of having an Action return various logical
>>>>>>forwards, which could map to various forms, and being able to
>>>>>>
> program
>
>>>>>>where those forms submit back to, all from within the
>>>>>>
> ActionMappings.
>
>>>>>>Matthias Bauer wrote:
>>>>>>
>>>>>>
>>>>>>>In the actions DisplayInsertAction or DisplayUpdateAction
>>>>>>>
> respectively,
>
>>>>I store
>>>>
>>>>>>>a state value in session scope which is checked in ProcessAction
>>>>>>>
> and
>
>>>>upon with I
>>>>
>>>>>>>decide whether to do an update or insert.
>>>>>>>
>>>>>>>With this pattern I do not really see the necessity to dynamically
>>>>>>>
> set
>
>>>>the
>>>>
>>>>>>>action attribute in forms.
>>>>>>>
>>>>>>>Do I miss something?
>>>>>>>
>>>>>>>--- Matthias
>>>>>>>
>>>>>>>Ted Husted wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>The general idea I'm playing with now is
>>>>>>>>
>>>>>>>>1) Extend ActionMappings with "request" and "actionPath"
>>>>>>>>
> properties.
>
>>>>>>>>2) Extend ActionServlet to place the ActionMapping in the request
>>>>>>>>context if request=true.
>>>>>>>>
>>>>>>>>3) Extend html:form to check for ActionMapping.getActionPath()
>>>>>>>>
> when the
>
>>>>>>>>path is not specified.
>>>>>>>>
>>>>>>>>So in struts-config you could specify
>>>>>>>>
>>>>>>>>request="true"
>>>>>>>>actionPath="/insertAction"
>>>>>>>>parameter="insert"
>>>>>>>>
>>>>>>>>or
>>>>>>>>
>>>>>>>>request="true"
>>>>>>>>actionPath="/updateAction"
>>>>>>>>parameter="update"
>>>>>>>>
>>>>>>>>and have the appropriate path automagically appear in your
>>>>>>>>
> html:form.
>
>>>>>>>>The Action can then call getParameter() to determine whether it's
>>>>>>>>suppose to insert or update the ActionForm data. Viola, no hidden
>>>>>>>>fields!
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>-- Ted Husted, Husted dot Com, Fairport NY USA.
>>-- Custom Software ~ Technical Services.
>>-- Tel 716 737-3463.
>>-- http://www.husted.com/about/struts/
>>
>>
>
Re: ActionMapping Workflows
Posted by Martin Cooper <ma...@tumbleweed.com>.
Right now, what I have is a combination of code fragments, pseudo-code, and
stuff that's still in my head. I expect to turn this into real code in the
next day or so.
Point taken regarding not implying an implementation. I agree with your
restatement of the real requirement. My near-term implementation may still
be a stack, though. :-}
--
Martin Cooper
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Tuesday, July 10, 2001 2:16 PM
Subject: Re: ActionMapping Workflows
> I'm liking the ActionRequest idea. I've tried similar things, but needed
> the parameter map idea.
>
> Do you have any code yet?
>
> I agree that leveraging ActionForwards sounds like the way to go.
>
> As to the requirements Matthias started, I would change 3 to
>
> 3. The ability to call (or nest) another workflow and return to the
> current step when the called workflow is complete.
>
> So as to not imply a particular implementation.
>
> Martin Cooper wrote:
> >
> > I have a similar concern. In addition, there may be runtime parameter
> > values that need to be passed along, particularly when actions are
chained
> > (something I do a lot of).
> >
> > I am working on something related, in conjunction with what Matthias
> > referred to as a return stack. The goal is to be able to handle "go back
to
> > where you came from" requests, where the specification of the actual
> > destination could require multiple dynamic parameters.
> >
> > The idea is that there is something called an ActionRequest, which is
> > essentially a combination of an ActionForward and a parameter Map, with
> > some "smarts" added in. A stack of these objects is kept in the session.
> > When one is popped off the stack, the "smarts" will find the appropriate
> > form bean type, populate one from the parameter map, forward the request
as
> > appropriate, and have Struts invoke the target action with this new form
> > bean instead of the one it would normally get.
> >
> > I haven't fully figured this out yet, and there are some pieces of the
> > puzzle I'm still working through. It's pretty clearly targetted at using
> > forwards to chain actions, but it should be able to be extended to work
> > with redirects, forwards to JSPs, etc.
> >
> > Thoughts, anyone?
> >
> > --
> > Martin Cooper
> >
> > At 08:35 AM 7/10/01, Robbin L. Gratz wrote:
> >
> > >Another point that I believe is getting ignored on the workflow stuff
is how
> > >is data getting transferred between the different steps. In the system
I
> > >just worked on, we had a number of two or more step workflows that were
used
> > >within other larger workflows. The output from these "sub workflows"
needed
> > >to be captured along the way to accomplish the parent workflow. My
thought
> > >was to have a controlling action whose associated data/form object
stores
> > >the data retrieved from the various steps of a workflow, whether these
steps
> > >were individual actions or another workflow process. Any thoughts from
> > >anyone or has someone solved this issue more elegantly?
> > >
> > >-----Original Message-----
> > >From: Jonathan [mailto:jasbell@i-2000.com]
> > >Sent: Tuesday, July 10, 2001 8:35 AM
> > >To: struts-dev@jakarta.apache.org; Matthias.Bauer@livinglogic.de
> > >Subject: Re: ActionMapping Workflows
> > >
> > >
> > >Can I ask how you all are thinking about bouncing around between steps
in
> > >the workflow? Is it a stack that each step gets popped off? Arent
workflow
> > >steps cyclical sometimes? Developers talk alot about graphing
workflows but
> > >I have not read about the implementation.
> > >
> > >
> > >----- Original Message -----
> > >From: "Matthias Bauer" <Ma...@livinglogic.de>
> > >To: <st...@jakarta.apache.org>
> > >Sent: Tuesday, July 10, 2001 9:12 AM
> > >Subject: Re: ActionMapping Workflows
> > >
> > >
> > > > Ok, that's fine with me and it makes pretty much sense. However,
this will
> > >not
> > > > be enough to implement workflow completely. It is just a little step
> > >toward
> > > > workflow control as a whole, just the same as the simple workflow
> > >extension I
> > > > already proposed together with some code on this list.
> > > >
> > > > I think all this should be put together to come up with a reasonable
> > >concept how
> > > > to implement workflow, instead of multiple single efforts to
implement
> > >some
> > > > single aspects only.
> > > >
> > > > Is there a team working on that?
> > > >
> > > > --- Matthias
> > > >
> > > >
> > > >
> > > > Ted Husted wrote:
> > > >
> > > > > I suppose storing the information in the session would work.
Though, I
> > > > > imagine this means the state value would be hardcoded into the
Java
> > > > > source. I'm working toward scripting workflows from within the
> > > > > ActionMappings, and would like to be able to reroute the flow
without
> > > > > changing the Java source.
> > > > >
> > > > > The insert/update flow is one example. Another would be inserting
one
> > > > > record and stopping, or inserting one record type and then another
type
> > > > > (and another type). Like say, creating a new vendor account, and
then a
> > > > > contact record for the account, and then a new stock item for the
> > > > > account. With a dynamic action path, you can script something like
this
> > > > > from the ActionMappings alone, without modifying the JSPs or Java
> > > > > source.
> > > > >
> > > > > I'm also now thinking that, given a dynamic action path, the best
place
> > > > > to represent it may be the ActionForward after all. This would
change
> > > > > the struts-config in my last post to:
> > > > >
> > > > > <action ...>
> > > > > <forward
> > > > > name="continue"
> > > > > path="/WEB-INF/pages/script/Form.jsp"
> > > > > request="true"
> > > > > actionPath="/script/Insert"/>
> > > > > </action>
> > > > >
> > > > > which supports the idea of having an Action return various logical
> > > > > forwards, which could map to various forms, and being able to
program
> > > > > where those forms submit back to, all from within the
ActionMappings.
> > > > >
> > > > > Matthias Bauer wrote:
> > > > >
> > > > >>In the actions DisplayInsertAction or DisplayUpdateAction
respectively,
> > >I store
> > > > >>a state value in session scope which is checked in ProcessAction
and
> > >upon with I
> > > > >>decide whether to do an update or insert.
> > > > >>
> > > > >>With this pattern I do not really see the necessity to dynamically
set
> > >the
> > > > >>action attribute in forms.
> > > > >>
> > > > >>Do I miss something?
> > > > >>
> > > > >>--- Matthias
> > > > >>
> > > > >>Ted Husted wrote:
> > > > >>
> > > > >>
> > > > >>>The general idea I'm playing with now is
> > > > >>>
> > > > >>>1) Extend ActionMappings with "request" and "actionPath"
properties.
> > > > >>>
> > > > >>>2) Extend ActionServlet to place the ActionMapping in the request
> > > > >>>context if request=true.
> > > > >>>
> > > > >>>3) Extend html:form to check for ActionMapping.getActionPath()
when the
> > > > >>>path is not specified.
> > > > >>>
> > > > >>>So in struts-config you could specify
> > > > >>>
> > > > >>>request="true"
> > > > >>>actionPath="/insertAction"
> > > > >>>parameter="insert"
> > > > >>>
> > > > >>>or
> > > > >>>
> > > > >>>request="true"
> > > > >>>actionPath="/updateAction"
> > > > >>>parameter="update"
> > > > >>>
> > > > >>>and have the appropriate path automagically appear in your
html:form.
> > > > >>>The Action can then call getParameter() to determine whether it's
> > > > >>>suppose to insert or update the ActionForm data. Viola, no hidden
> > > > >>>fields!
> > > > >>>
> > > >
> > > >
> > > >
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
Re: ActionMapping Workflows
Posted by Ted Husted <hu...@apache.org>.
I agree that the idea of lock-step stack doesn't seem to fit well within
a Web application.
A more useful idea might be a cursor that tracked the farthest step
reached. The entry point of the workflow (step 1) could "fast-forward"
if a cursor for that workflow was present. The cursor might be one of
the "ActionRequest" objects that Martin suggested. In effect, each step
of the workflow would be setting a bookmark, so the actor can be
returned to whereever they left off if the workflow were re-entered.
If the workflow needs to branch, then the branch might store that same
cursor at its tail somehow, so when the workflow completed, "success" at
the last step could bring it back to the calling workflow (rather than a
menu).
With dynamic action paths, each step of the workflow would be able to
set a form to submit back to one it's own mappings, and keep the chain
intact.
With a resource cache, the workflow would have a place to store
temporary data until the workflow completes, at which point the final
step could remove any workflow objects from the cache.
"Robbin L. Gratz" wrote:
>
> With the "return stack" concept, I'm assuming this will be a session scope
> variable. What happens when the user clicks the back button rather than
> going through the process the app provides? Now the session is out of synch
> with the actual position in the process that the user is in. It seems to me
> that there has to be some sort of request/page scope data item in the form
> of a hidden variable or link parameter that indicates what position in the
> process the user is in. I had thought about the stack concept before but
> couldn't get past this problem. Has anyone else come up with a solution?
RE: ActionMapping Workflows
Posted by David Winterfeldt <dw...@yahoo.com>.
Maybe the token that can be generated in an action be
used or make a workflow token.
David
--- "Robbin L. Gratz" <rg...@momentumsoftware.com>
wrote:
>
>
> With the "return stack" concept, I'm assuming this
> will be a session scope
> variable. What happens when the user clicks the
> back button rather than
> going through the process the app provides? Now the
> session is out of synch
> with the actual position in the process that the
> user is in. It seems to me
> that there has to be some sort of request/page scope
> data item in the form
> of a hidden variable or link parameter that
> indicates what position in the
> process the user is in. I had thought about the
> stack concept before but
> couldn't get past this problem. Has anyone else
> come up with a solution?
>
>
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Tuesday, July 10, 2001 4:16 PM
> To: struts-dev@jakarta.apache.org
> Subject: Re: ActionMapping Workflows
>
>
> I'm liking the ActionRequest idea. I've tried
> similar things, but needed
> the parameter map idea.
>
> Do you have any code yet?
>
> I agree that leveraging ActionForwards sounds like
> the way to go.
>
> As to the requirements Matthias started, I would
> change 3 to
>
> 3. The ability to call (or nest) another workflow
> and return to the
> current step when the called workflow is complete.
>
> So as to not imply a particular implementation.
>
> Martin Cooper wrote:
> >
> > I have a similar concern. In addition, there may
> be runtime parameter
> > values that need to be passed along, particularly
> when actions are chained
> > (something I do a lot of).
> >
> > I am working on something related, in conjunction
> with what Matthias
> > referred to as a return stack. The goal is to be
> able to handle "go back
> to
> > where you came from" requests, where the
> specification of the actual
> > destination could require multiple dynamic
> parameters.
> >
> > The idea is that there is something called an
> ActionRequest, which is
> > essentially a combination of an ActionForward and
> a parameter Map, with
> > some "smarts" added in. A stack of these objects
> is kept in the session.
> > When one is popped off the stack, the "smarts"
> will find the appropriate
> > form bean type, populate one from the parameter
> map, forward the request
> as
> > appropriate, and have Struts invoke the target
> action with this new form
> > bean instead of the one it would normally get.
> >
> > I haven't fully figured this out yet, and there
> are some pieces of the
> > puzzle I'm still working through. It's pretty
> clearly targetted at using
> > forwards to chain actions, but it should be able
> to be extended to work
> > with redirects, forwards to JSPs, etc.
> >
> > Thoughts, anyone?
> >
> > --
> > Martin Cooper
> >
> > At 08:35 AM 7/10/01, Robbin L. Gratz wrote:
> >
> > >Another point that I believe is getting ignored
> on the workflow stuff is
> how
> > >is data getting transferred between the different
> steps. In the system I
> > >just worked on, we had a number of two or more
> step workflows that were
> used
> > >within other larger workflows. The output from
> these "sub workflows"
> needed
> > >to be captured along the way to accomplish the
> parent workflow. My
> thought
> > >was to have a controlling action whose associated
> data/form object stores
> > >the data retrieved from the various steps of a
> workflow, whether these
> steps
> > >were individual actions or another workflow
> process. Any thoughts from
> > >anyone or has someone solved this issue more
> elegantly?
> > >
> > >-----Original Message-----
> > >From: Jonathan [mailto:jasbell@i-2000.com]
> > >Sent: Tuesday, July 10, 2001 8:35 AM
> > >To: struts-dev@jakarta.apache.org;
> Matthias.Bauer@livinglogic.de
> > >Subject: Re: ActionMapping Workflows
> > >
> > >
> > >Can I ask how you all are thinking about bouncing
> around between steps in
> > >the workflow? Is it a stack that each step gets
> popped off? Arent
> workflow
> > >steps cyclical sometimes? Developers talk alot
> about graphing workflows
> but
> > >I have not read about the implementation.
> > >
> > >
> > >----- Original Message -----
> > >From: "Matthias Bauer"
> <Ma...@livinglogic.de>
> > >To: <st...@jakarta.apache.org>
> > >Sent: Tuesday, July 10, 2001 9:12 AM
> > >Subject: Re: ActionMapping Workflows
> > >
> > >
> > > > Ok, that's fine with me and it makes pretty
> much sense. However, this
> will
> > >not
> > > > be enough to implement workflow completely. It
> is just a little step
> > >toward
> > > > workflow control as a whole, just the same as
> the simple workflow
> > >extension I
> > > > already proposed together with some code on
> this list.
> > > >
> > > > I think all this should be put together to
> come up with a reasonable
> > >concept how
> > > > to implement workflow, instead of multiple
> single efforts to implement
> > >some
> > > > single aspects only.
> > > >
> > > > Is there a team working on that?
> > > >
> > > > --- Matthias
> > > >
> > > >
> > > >
> > > > Ted Husted wrote:
> > > >
> > > > > I suppose storing the information in the
> session would work. Though,
> I
> > > > > imagine this means the state value would be
> hardcoded into the Java
> > > > > source. I'm working toward scripting
> workflows from within the
> > > > > ActionMappings, and would like to be able to
> reroute the flow
> without
> > > > > changing the Java source.
> > > > >
> > > > > The insert/update flow is one example.
> Another would be inserting
> one
> > > > > record and stopping, or inserting one record
> type and then another
> type
> > > > > (and another type). Like say, creating a new
> vendor account, and
> then a
> > > > > contact record for the account, and then a
> new stock item for the
> > > > > account. With a dynamic action path, you can
> script something like
> this
> > > > > from the ActionMappings alone, without
> modifying the JSPs or Java
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
RE: ActionMapping Workflows
Posted by "Robbin L. Gratz" <rg...@momentumsoftware.com>.
With the "return stack" concept, I'm assuming this will be a session scope
variable. What happens when the user clicks the back button rather than
going through the process the app provides? Now the session is out of synch
with the actual position in the process that the user is in. It seems to me
that there has to be some sort of request/page scope data item in the form
of a hidden variable or link parameter that indicates what position in the
process the user is in. I had thought about the stack concept before but
couldn't get past this problem. Has anyone else come up with a solution?
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Tuesday, July 10, 2001 4:16 PM
To: struts-dev@jakarta.apache.org
Subject: Re: ActionMapping Workflows
I'm liking the ActionRequest idea. I've tried similar things, but needed
the parameter map idea.
Do you have any code yet?
I agree that leveraging ActionForwards sounds like the way to go.
As to the requirements Matthias started, I would change 3 to
3. The ability to call (or nest) another workflow and return to the
current step when the called workflow is complete.
So as to not imply a particular implementation.
Martin Cooper wrote:
>
> I have a similar concern. In addition, there may be runtime parameter
> values that need to be passed along, particularly when actions are chained
> (something I do a lot of).
>
> I am working on something related, in conjunction with what Matthias
> referred to as a return stack. The goal is to be able to handle "go back
to
> where you came from" requests, where the specification of the actual
> destination could require multiple dynamic parameters.
>
> The idea is that there is something called an ActionRequest, which is
> essentially a combination of an ActionForward and a parameter Map, with
> some "smarts" added in. A stack of these objects is kept in the session.
> When one is popped off the stack, the "smarts" will find the appropriate
> form bean type, populate one from the parameter map, forward the request
as
> appropriate, and have Struts invoke the target action with this new form
> bean instead of the one it would normally get.
>
> I haven't fully figured this out yet, and there are some pieces of the
> puzzle I'm still working through. It's pretty clearly targetted at using
> forwards to chain actions, but it should be able to be extended to work
> with redirects, forwards to JSPs, etc.
>
> Thoughts, anyone?
>
> --
> Martin Cooper
>
> At 08:35 AM 7/10/01, Robbin L. Gratz wrote:
>
> >Another point that I believe is getting ignored on the workflow stuff is
how
> >is data getting transferred between the different steps. In the system I
> >just worked on, we had a number of two or more step workflows that were
used
> >within other larger workflows. The output from these "sub workflows"
needed
> >to be captured along the way to accomplish the parent workflow. My
thought
> >was to have a controlling action whose associated data/form object stores
> >the data retrieved from the various steps of a workflow, whether these
steps
> >were individual actions or another workflow process. Any thoughts from
> >anyone or has someone solved this issue more elegantly?
> >
> >-----Original Message-----
> >From: Jonathan [mailto:jasbell@i-2000.com]
> >Sent: Tuesday, July 10, 2001 8:35 AM
> >To: struts-dev@jakarta.apache.org; Matthias.Bauer@livinglogic.de
> >Subject: Re: ActionMapping Workflows
> >
> >
> >Can I ask how you all are thinking about bouncing around between steps in
> >the workflow? Is it a stack that each step gets popped off? Arent
workflow
> >steps cyclical sometimes? Developers talk alot about graphing workflows
but
> >I have not read about the implementation.
> >
> >
> >----- Original Message -----
> >From: "Matthias Bauer" <Ma...@livinglogic.de>
> >To: <st...@jakarta.apache.org>
> >Sent: Tuesday, July 10, 2001 9:12 AM
> >Subject: Re: ActionMapping Workflows
> >
> >
> > > Ok, that's fine with me and it makes pretty much sense. However, this
will
> >not
> > > be enough to implement workflow completely. It is just a little step
> >toward
> > > workflow control as a whole, just the same as the simple workflow
> >extension I
> > > already proposed together with some code on this list.
> > >
> > > I think all this should be put together to come up with a reasonable
> >concept how
> > > to implement workflow, instead of multiple single efforts to implement
> >some
> > > single aspects only.
> > >
> > > Is there a team working on that?
> > >
> > > --- Matthias
> > >
> > >
> > >
> > > Ted Husted wrote:
> > >
> > > > I suppose storing the information in the session would work. Though,
I
> > > > imagine this means the state value would be hardcoded into the Java
> > > > source. I'm working toward scripting workflows from within the
> > > > ActionMappings, and would like to be able to reroute the flow
without
> > > > changing the Java source.
> > > >
> > > > The insert/update flow is one example. Another would be inserting
one
> > > > record and stopping, or inserting one record type and then another
type
> > > > (and another type). Like say, creating a new vendor account, and
then a
> > > > contact record for the account, and then a new stock item for the
> > > > account. With a dynamic action path, you can script something like
this
> > > > from the ActionMappings alone, without modifying the JSPs or Java
> > > > source.
> > > >
> > > > I'm also now thinking that, given a dynamic action path, the best
place
> > > > to represent it may be the ActionForward after all. This would
change
> > > > the struts-config in my last post to:
> > > >
> > > > <action ...>
> > > > <forward
> > > > name="continue"
> > > > path="/WEB-INF/pages/script/Form.jsp"
> > > > request="true"
> > > > actionPath="/script/Insert"/>
> > > > </action>
> > > >
> > > > which supports the idea of having an Action return various logical
> > > > forwards, which could map to various forms, and being able to
program
> > > > where those forms submit back to, all from within the
ActionMappings.
> > > >
> > > > Matthias Bauer wrote:
> > > >
> > > >>In the actions DisplayInsertAction or DisplayUpdateAction
respectively,
> >I store
> > > >>a state value in session scope which is checked in ProcessAction and
> >upon with I
> > > >>decide whether to do an update or insert.
> > > >>
> > > >>With this pattern I do not really see the necessity to dynamically
set
> >the
> > > >>action attribute in forms.
> > > >>
> > > >>Do I miss something?
> > > >>
> > > >>--- Matthias
> > > >>
> > > >>Ted Husted wrote:
> > > >>
> > > >>
> > > >>>The general idea I'm playing with now is
> > > >>>
> > > >>>1) Extend ActionMappings with "request" and "actionPath"
properties.
> > > >>>
> > > >>>2) Extend ActionServlet to place the ActionMapping in the request
> > > >>>context if request=true.
> > > >>>
> > > >>>3) Extend html:form to check for ActionMapping.getActionPath() when
the
> > > >>>path is not specified.
> > > >>>
> > > >>>So in struts-config you could specify
> > > >>>
> > > >>>request="true"
> > > >>>actionPath="/insertAction"
> > > >>>parameter="insert"
> > > >>>
> > > >>>or
> > > >>>
> > > >>>request="true"
> > > >>>actionPath="/updateAction"
> > > >>>parameter="update"
> > > >>>
> > > >>>and have the appropriate path automagically appear in your
html:form.
> > > >>>The Action can then call getParameter() to determine whether it's
> > > >>>suppose to insert or update the ActionForm data. Viola, no hidden
> > > >>>fields!
> > > >>>
> > >
> > >
> > >
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Re: ActionMapping Workflows
Posted by Ted Husted <hu...@apache.org>.
I'm liking the ActionRequest idea. I've tried similar things, but needed
the parameter map idea.
Do you have any code yet?
I agree that leveraging ActionForwards sounds like the way to go.
As to the requirements Matthias started, I would change 3 to
3. The ability to call (or nest) another workflow and return to the
current step when the called workflow is complete.
So as to not imply a particular implementation.
Martin Cooper wrote:
>
> I have a similar concern. In addition, there may be runtime parameter
> values that need to be passed along, particularly when actions are chained
> (something I do a lot of).
>
> I am working on something related, in conjunction with what Matthias
> referred to as a return stack. The goal is to be able to handle "go back to
> where you came from" requests, where the specification of the actual
> destination could require multiple dynamic parameters.
>
> The idea is that there is something called an ActionRequest, which is
> essentially a combination of an ActionForward and a parameter Map, with
> some "smarts" added in. A stack of these objects is kept in the session.
> When one is popped off the stack, the "smarts" will find the appropriate
> form bean type, populate one from the parameter map, forward the request as
> appropriate, and have Struts invoke the target action with this new form
> bean instead of the one it would normally get.
>
> I haven't fully figured this out yet, and there are some pieces of the
> puzzle I'm still working through. It's pretty clearly targetted at using
> forwards to chain actions, but it should be able to be extended to work
> with redirects, forwards to JSPs, etc.
>
> Thoughts, anyone?
>
> --
> Martin Cooper
>
> At 08:35 AM 7/10/01, Robbin L. Gratz wrote:
>
> >Another point that I believe is getting ignored on the workflow stuff is how
> >is data getting transferred between the different steps. In the system I
> >just worked on, we had a number of two or more step workflows that were used
> >within other larger workflows. The output from these "sub workflows" needed
> >to be captured along the way to accomplish the parent workflow. My thought
> >was to have a controlling action whose associated data/form object stores
> >the data retrieved from the various steps of a workflow, whether these steps
> >were individual actions or another workflow process. Any thoughts from
> >anyone or has someone solved this issue more elegantly?
> >
> >-----Original Message-----
> >From: Jonathan [mailto:jasbell@i-2000.com]
> >Sent: Tuesday, July 10, 2001 8:35 AM
> >To: struts-dev@jakarta.apache.org; Matthias.Bauer@livinglogic.de
> >Subject: Re: ActionMapping Workflows
> >
> >
> >Can I ask how you all are thinking about bouncing around between steps in
> >the workflow? Is it a stack that each step gets popped off? Arent workflow
> >steps cyclical sometimes? Developers talk alot about graphing workflows but
> >I have not read about the implementation.
> >
> >
> >----- Original Message -----
> >From: "Matthias Bauer" <Ma...@livinglogic.de>
> >To: <st...@jakarta.apache.org>
> >Sent: Tuesday, July 10, 2001 9:12 AM
> >Subject: Re: ActionMapping Workflows
> >
> >
> > > Ok, that's fine with me and it makes pretty much sense. However, this will
> >not
> > > be enough to implement workflow completely. It is just a little step
> >toward
> > > workflow control as a whole, just the same as the simple workflow
> >extension I
> > > already proposed together with some code on this list.
> > >
> > > I think all this should be put together to come up with a reasonable
> >concept how
> > > to implement workflow, instead of multiple single efforts to implement
> >some
> > > single aspects only.
> > >
> > > Is there a team working on that?
> > >
> > > --- Matthias
> > >
> > >
> > >
> > > Ted Husted wrote:
> > >
> > > > I suppose storing the information in the session would work. Though, I
> > > > imagine this means the state value would be hardcoded into the Java
> > > > source. I'm working toward scripting workflows from within the
> > > > ActionMappings, and would like to be able to reroute the flow without
> > > > changing the Java source.
> > > >
> > > > The insert/update flow is one example. Another would be inserting one
> > > > record and stopping, or inserting one record type and then another type
> > > > (and another type). Like say, creating a new vendor account, and then a
> > > > contact record for the account, and then a new stock item for the
> > > > account. With a dynamic action path, you can script something like this
> > > > from the ActionMappings alone, without modifying the JSPs or Java
> > > > source.
> > > >
> > > > I'm also now thinking that, given a dynamic action path, the best place
> > > > to represent it may be the ActionForward after all. This would change
> > > > the struts-config in my last post to:
> > > >
> > > > <action ...>
> > > > <forward
> > > > name="continue"
> > > > path="/WEB-INF/pages/script/Form.jsp"
> > > > request="true"
> > > > actionPath="/script/Insert"/>
> > > > </action>
> > > >
> > > > which supports the idea of having an Action return various logical
> > > > forwards, which could map to various forms, and being able to program
> > > > where those forms submit back to, all from within the ActionMappings.
> > > >
> > > > Matthias Bauer wrote:
> > > >
> > > >>In the actions DisplayInsertAction or DisplayUpdateAction respectively,
> >I store
> > > >>a state value in session scope which is checked in ProcessAction and
> >upon with I
> > > >>decide whether to do an update or insert.
> > > >>
> > > >>With this pattern I do not really see the necessity to dynamically set
> >the
> > > >>action attribute in forms.
> > > >>
> > > >>Do I miss something?
> > > >>
> > > >>--- Matthias
> > > >>
> > > >>Ted Husted wrote:
> > > >>
> > > >>
> > > >>>The general idea I'm playing with now is
> > > >>>
> > > >>>1) Extend ActionMappings with "request" and "actionPath" properties.
> > > >>>
> > > >>>2) Extend ActionServlet to place the ActionMapping in the request
> > > >>>context if request=true.
> > > >>>
> > > >>>3) Extend html:form to check for ActionMapping.getActionPath() when the
> > > >>>path is not specified.
> > > >>>
> > > >>>So in struts-config you could specify
> > > >>>
> > > >>>request="true"
> > > >>>actionPath="/insertAction"
> > > >>>parameter="insert"
> > > >>>
> > > >>>or
> > > >>>
> > > >>>request="true"
> > > >>>actionPath="/updateAction"
> > > >>>parameter="update"
> > > >>>
> > > >>>and have the appropriate path automagically appear in your html:form.
> > > >>>The Action can then call getParameter() to determine whether it's
> > > >>>suppose to insert or update the ActionForm data. Viola, no hidden
> > > >>>fields!
> > > >>>
> > >
> > >
> > >
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
RE: ActionMapping Workflows
Posted by Martin Cooper <ma...@tumbleweed.com>.
I have a similar concern. In addition, there may be runtime parameter
values that need to be passed along, particularly when actions are chained
(something I do a lot of).
I am working on something related, in conjunction with what Matthias
referred to as a return stack. The goal is to be able to handle "go back to
where you came from" requests, where the specification of the actual
destination could require multiple dynamic parameters.
The idea is that there is something called an ActionRequest, which is
essentially a combination of an ActionForward and a parameter Map, with
some "smarts" added in. A stack of these objects is kept in the session.
When one is popped off the stack, the "smarts" will find the appropriate
form bean type, populate one from the parameter map, forward the request as
appropriate, and have Struts invoke the target action with this new form
bean instead of the one it would normally get.
I haven't fully figured this out yet, and there are some pieces of the
puzzle I'm still working through. It's pretty clearly targetted at using
forwards to chain actions, but it should be able to be extended to work
with redirects, forwards to JSPs, etc.
Thoughts, anyone?
--
Martin Cooper
At 08:35 AM 7/10/01, Robbin L. Gratz wrote:
>Another point that I believe is getting ignored on the workflow stuff is how
>is data getting transferred between the different steps. In the system I
>just worked on, we had a number of two or more step workflows that were used
>within other larger workflows. The output from these "sub workflows" needed
>to be captured along the way to accomplish the parent workflow. My thought
>was to have a controlling action whose associated data/form object stores
>the data retrieved from the various steps of a workflow, whether these steps
>were individual actions or another workflow process. Any thoughts from
>anyone or has someone solved this issue more elegantly?
>
>-----Original Message-----
>From: Jonathan [mailto:jasbell@i-2000.com]
>Sent: Tuesday, July 10, 2001 8:35 AM
>To: struts-dev@jakarta.apache.org; Matthias.Bauer@livinglogic.de
>Subject: Re: ActionMapping Workflows
>
>
>Can I ask how you all are thinking about bouncing around between steps in
>the workflow? Is it a stack that each step gets popped off? Arent workflow
>steps cyclical sometimes? Developers talk alot about graphing workflows but
>I have not read about the implementation.
>
>
>----- Original Message -----
>From: "Matthias Bauer" <Ma...@livinglogic.de>
>To: <st...@jakarta.apache.org>
>Sent: Tuesday, July 10, 2001 9:12 AM
>Subject: Re: ActionMapping Workflows
>
>
> > Ok, that's fine with me and it makes pretty much sense. However, this will
>not
> > be enough to implement workflow completely. It is just a little step
>toward
> > workflow control as a whole, just the same as the simple workflow
>extension I
> > already proposed together with some code on this list.
> >
> > I think all this should be put together to come up with a reasonable
>concept how
> > to implement workflow, instead of multiple single efforts to implement
>some
> > single aspects only.
> >
> > Is there a team working on that?
> >
> > --- Matthias
> >
> >
> >
> > Ted Husted wrote:
> >
> > > I suppose storing the information in the session would work. Though, I
> > > imagine this means the state value would be hardcoded into the Java
> > > source. I'm working toward scripting workflows from within the
> > > ActionMappings, and would like to be able to reroute the flow without
> > > changing the Java source.
> > >
> > > The insert/update flow is one example. Another would be inserting one
> > > record and stopping, or inserting one record type and then another type
> > > (and another type). Like say, creating a new vendor account, and then a
> > > contact record for the account, and then a new stock item for the
> > > account. With a dynamic action path, you can script something like this
> > > from the ActionMappings alone, without modifying the JSPs or Java
> > > source.
> > >
> > > I'm also now thinking that, given a dynamic action path, the best place
> > > to represent it may be the ActionForward after all. This would change
> > > the struts-config in my last post to:
> > >
> > > <action ...>
> > > <forward
> > > name="continue"
> > > path="/WEB-INF/pages/script/Form.jsp"
> > > request="true"
> > > actionPath="/script/Insert"/>
> > > </action>
> > >
> > > which supports the idea of having an Action return various logical
> > > forwards, which could map to various forms, and being able to program
> > > where those forms submit back to, all from within the ActionMappings.
> > >
> > > Matthias Bauer wrote:
> > >
> > >>In the actions DisplayInsertAction or DisplayUpdateAction respectively,
>I store
> > >>a state value in session scope which is checked in ProcessAction and
>upon with I
> > >>decide whether to do an update or insert.
> > >>
> > >>With this pattern I do not really see the necessity to dynamically set
>the
> > >>action attribute in forms.
> > >>
> > >>Do I miss something?
> > >>
> > >>--- Matthias
> > >>
> > >>Ted Husted wrote:
> > >>
> > >>
> > >>>The general idea I'm playing with now is
> > >>>
> > >>>1) Extend ActionMappings with "request" and "actionPath" properties.
> > >>>
> > >>>2) Extend ActionServlet to place the ActionMapping in the request
> > >>>context if request=true.
> > >>>
> > >>>3) Extend html:form to check for ActionMapping.getActionPath() when the
> > >>>path is not specified.
> > >>>
> > >>>So in struts-config you could specify
> > >>>
> > >>>request="true"
> > >>>actionPath="/insertAction"
> > >>>parameter="insert"
> > >>>
> > >>>or
> > >>>
> > >>>request="true"
> > >>>actionPath="/updateAction"
> > >>>parameter="update"
> > >>>
> > >>>and have the appropriate path automagically appear in your html:form.
> > >>>The Action can then call getParameter() to determine whether it's
> > >>>suppose to insert or update the ActionForm data. Viola, no hidden
> > >>>fields!
> > >>>
> >
> >
> >
Re: ActionMapping Workflows
Posted by Ted Husted <hu...@apache.org>.
I'm thinking about scripting workflows through the ActionMappings.
Each step in the flow would be a mapping, and the ways the steps could
branch would be local forwards for those mappings. As you progress
through the workflow, the Action decides which logical forward to
return.
I'm finding that if we can specify the path for a html:form path
dynamically, then it becomes much easier to plug an ActionForm into a
different context and have it submit back to the current "workflow
mapping", and have a different set of local forwards available to the
Action.
I'll be making more sample code available as it is developed.
Jonathan wrote:
>
> Can I ask how you all are thinking about bouncing around between steps in
> the workflow? Is it a stack that each step gets popped off? Arent workflow
> steps cyclical sometimes? Developers talk alot about graphing workflows but
> I have not read about the implementation.
Re: ActionMapping Workflows
Posted by Paul Speed <Pa...@metrixpoint.com>.
One thing you may want to consider when tucking workflow data away
is the scope of the data. For example, if I jump out of the normal
workflow to do some object creation that will eventually be used by
the original workflow, the sub-workflow should probably not be able
to access the data of the original workflow other than what was
explicitly granted. This makes the contract between the outer workflow
and sub-workflow explicit and gives the subworkflow a place to play
with data without worrying about namespace-type collisions, etc..
It sort of works similar to a method in a way. A subworkflow has
specific values it takes as an initial environment (parameters of
sorts) and returns a set of values when finished (a multi-valued
return of sorts.)
This also creates a sort of scope stack. As each sub-workflow
completes, it's scoped data will be "freed". When the outermost
workflow completes, you'll know that all scoped data is gone. A
good way to avoid an ever-increasing session size.
I'm not sure how any of this would transfer to struts, but I thought
I'd poke my general workflow $0.02 in anyway.
-Paul Speed
P.S.: Sometimes its even possible to build scoping on top of a more
generalized workflow approach. If you imagine workflow as simply
a set of states and transitions between them, then you can attach
custom logic to the states. Essentially, the state is where you
currently are. To move to another state you execute a specific
transition that takes you to another state. This transition can
do all sorts of things, like push a new local environment and add
initialized values from the old local environment, ie: implement
a scope-based data model. In this kind of case, it's also preferable
to have some code associated with the transition that actually chooses
the next state. (Instead of always hard-coding that transitions always
point to another state.) That way you can support "returns" from
sub-workflows that take you back to the state you were in before
starting the sub-workflow. And it goes on from there, so I'll stop
now. ;)
Ted Husted wrote:
>
> Something I have found generally useful is a "Resource Cache". This is
> just a hashtable in the session where I can (judiciously) tuck objects
> for future reference. In the case of a multiform workflow, each of the
> subforms could be saved to the cache, and then recalled as needed along
> the way.
>
> Of course, you could do the same with the session alone, but some
> containers get testy if you put too many objects in the session, and
> this also gives you the opportunity to do some oversight management in
> terms of how much gets cached.
>
> I first started to use this in relation to a "foreign key" strategy for
> my ActionForms, where they automatically cache the value of a property
> that another table may use as a foreign key. New forms then check the
> cache to pre-populate their own foreign keys.
>
> I also have a strategy where a form can be saved to the cache (using a
> special submit button) to be completed later. If the actor visits
> another form that is related to the first, when they return to the first
> form, the relation (foreign key) is automatically inserted.
>
> This would work even better in an EJB, where sessions can be
> automatically saved, or under 2.3 where we can have session listeners
> that could serialize the cache before the session expires.
>
> This could also be a good place to tuck a workflow stack, should one be
> needed.
>
> "Robbin L. Gratz" wrote:
> >
> > Another point that I believe is getting ignored on the workflow stuff is how
> > is data getting transferred between the different steps. In the system I
> > just worked on, we had a number of two or more step workflows that were used
> > within other larger workflows. The output from these "sub workflows" needed
> > to be captured along the way to accomplish the parent workflow. My thought
> > was to have a controlling action whose associated data/form object stores
> > the data retrieved from the various steps of a workflow, whether these steps
> > were individual actions or another workflow process. Any thoughts from
> > anyone or has someone solved this issue more elegantly?
Re: ActionMapping Workflows
Posted by Jonathan Asbell <ja...@i-2000.com>.
Why not try enforcing some kind of composition. For instance, a workflow
might have 5 steps. Separate the components themselves from the order in
which they must be carried out. That is, if you must do 5 steps, then one
"WorkflowObject" will be composed of 5 "StepObject" s. Upon completion of
each step you will add the current step that you have completed to the
WorkflowObject and then tell the WorkflowObject to check to see if all five
steps have been added. If not, then send them to the next step. I think
this is nothing new, as Actions, ActionMappings, and ActionForms kind of
behave like this in a form wizard situation. However, maybe we can leverage
the same objects by making "WorkflowObject" and "StepObject" interfaces, and
make some of our homemade struts components implement these interfaces.
----- Original Message -----
From: "David Winterfeldt" <dw...@yahoo.com>
To: <st...@jakarta.apache.org>
Sent: Tuesday, July 10, 2001 4:04 PM
Subject: Re: ActionMapping Workflows
> What your thinking of may already do this, but I
> thought I would mention this in case it didn't. If
> you end up contructing a workflow using the actions,
> it would be nice if it could be defined as a linked
> list (or at least kept track of the last action). So
> you wouldn't just go forward, but could be go back a
> step too. This would be nice for multi-page forms
> with a 'next' and 'previous' link so the JSP page
> wouldn't have the links hardcoded.
>
> David
>
> --- Ted Husted <hu...@apache.org> wrote:
> > Something I have found generally useful is a
> > "Resource Cache". This is
> > just a hashtable in the session where I can
> > (judiciously) tuck objects
> > for future reference. In the case of a multiform
> > workflow, each of the
> > subforms could be saved to the cache, and then
> > recalled as needed along
> > the way.
> >
> > Of course, you could do the same with the session
> > alone, but some
> > containers get testy if you put too many objects in
> > the session, and
> > this also gives you the opportunity to do some
> > oversight management in
> > terms of how much gets cached.
> >
> > I first started to use this in relation to a
> > "foreign key" strategy for
> > my ActionForms, where they automatically cache the
> > value of a property
> > that another table may use as a foreign key. New
> > forms then check the
> > cache to pre-populate their own foreign keys.
> >
> > I also have a strategy where a form can be saved to
> > the cache (using a
> > special submit button) to be completed later. If the
> > actor visits
> > another form that is related to the first, when they
> > return to the first
> > form, the relation (foreign key) is automatically
> > inserted.
> >
> > This would work even better in an EJB, where
> > sessions can be
> > automatically saved, or under 2.3 where we can have
> > session listeners
> > that could serialize the cache before the session
> > expires.
> >
> > This could also be a good place to tuck a workflow
> > stack, should one be
> > needed.
> >
> > "Robbin L. Gratz" wrote:
> > >
> > > Another point that I believe is getting ignored on
> > the workflow stuff is how
> > > is data getting transferred between the different
> > steps. In the system I
> > > just worked on, we had a number of two or more
> > step workflows that were used
> > > within other larger workflows. The output from
> > these "sub workflows" needed
> > > to be captured along the way to accomplish the
> > parent workflow. My thought
> > > was to have a controlling action whose associated
> > data/form object stores
> > > the data retrieved from the various steps of a
> > workflow, whether these steps
> > > were individual actions or another workflow
> > process. Any thoughts from
> > > anyone or has someone solved this issue more
> elegantly?
>
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
>
Re: ActionMapping Workflows
Posted by David Winterfeldt <dw...@yahoo.com>.
What your thinking of may already do this, but I
thought I would mention this in case it didn't. If
you end up contructing a workflow using the actions,
it would be nice if it could be defined as a linked
list (or at least kept track of the last action). So
you wouldn't just go forward, but could be go back a
step too. This would be nice for multi-page forms
with a 'next' and 'previous' link so the JSP page
wouldn't have the links hardcoded.
David
--- Ted Husted <hu...@apache.org> wrote:
> Something I have found generally useful is a
> "Resource Cache". This is
> just a hashtable in the session where I can
> (judiciously) tuck objects
> for future reference. In the case of a multiform
> workflow, each of the
> subforms could be saved to the cache, and then
> recalled as needed along
> the way.
>
> Of course, you could do the same with the session
> alone, but some
> containers get testy if you put too many objects in
> the session, and
> this also gives you the opportunity to do some
> oversight management in
> terms of how much gets cached.
>
> I first started to use this in relation to a
> "foreign key" strategy for
> my ActionForms, where they automatically cache the
> value of a property
> that another table may use as a foreign key. New
> forms then check the
> cache to pre-populate their own foreign keys.
>
> I also have a strategy where a form can be saved to
> the cache (using a
> special submit button) to be completed later. If the
> actor visits
> another form that is related to the first, when they
> return to the first
> form, the relation (foreign key) is automatically
> inserted.
>
> This would work even better in an EJB, where
> sessions can be
> automatically saved, or under 2.3 where we can have
> session listeners
> that could serialize the cache before the session
> expires.
>
> This could also be a good place to tuck a workflow
> stack, should one be
> needed.
>
> "Robbin L. Gratz" wrote:
> >
> > Another point that I believe is getting ignored on
> the workflow stuff is how
> > is data getting transferred between the different
> steps. In the system I
> > just worked on, we had a number of two or more
> step workflows that were used
> > within other larger workflows. The output from
> these "sub workflows" needed
> > to be captured along the way to accomplish the
> parent workflow. My thought
> > was to have a controlling action whose associated
> data/form object stores
> > the data retrieved from the various steps of a
> workflow, whether these steps
> > were individual actions or another workflow
> process. Any thoughts from
> > anyone or has someone solved this issue more
elegantly?
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: ActionMapping Workflows
Posted by Ted Husted <hu...@apache.org>.
Something I have found generally useful is a "Resource Cache". This is
just a hashtable in the session where I can (judiciously) tuck objects
for future reference. In the case of a multiform workflow, each of the
subforms could be saved to the cache, and then recalled as needed along
the way.
Of course, you could do the same with the session alone, but some
containers get testy if you put too many objects in the session, and
this also gives you the opportunity to do some oversight management in
terms of how much gets cached.
I first started to use this in relation to a "foreign key" strategy for
my ActionForms, where they automatically cache the value of a property
that another table may use as a foreign key. New forms then check the
cache to pre-populate their own foreign keys.
I also have a strategy where a form can be saved to the cache (using a
special submit button) to be completed later. If the actor visits
another form that is related to the first, when they return to the first
form, the relation (foreign key) is automatically inserted.
This would work even better in an EJB, where sessions can be
automatically saved, or under 2.3 where we can have session listeners
that could serialize the cache before the session expires.
This could also be a good place to tuck a workflow stack, should one be
needed.
"Robbin L. Gratz" wrote:
>
> Another point that I believe is getting ignored on the workflow stuff is how
> is data getting transferred between the different steps. In the system I
> just worked on, we had a number of two or more step workflows that were used
> within other larger workflows. The output from these "sub workflows" needed
> to be captured along the way to accomplish the parent workflow. My thought
> was to have a controlling action whose associated data/form object stores
> the data retrieved from the various steps of a workflow, whether these steps
> were individual actions or another workflow process. Any thoughts from
> anyone or has someone solved this issue more elegantly?
RE: ActionMapping Workflows
Posted by "Robbin L. Gratz" <rg...@momentumsoftware.com>.
Another point that I believe is getting ignored on the workflow stuff is how
is data getting transferred between the different steps. In the system I
just worked on, we had a number of two or more step workflows that were used
within other larger workflows. The output from these "sub workflows" needed
to be captured along the way to accomplish the parent workflow. My thought
was to have a controlling action whose associated data/form object stores
the data retrieved from the various steps of a workflow, whether these steps
were individual actions or another workflow process. Any thoughts from
anyone or has someone solved this issue more elegantly?
-----Original Message-----
From: Jonathan [mailto:jasbell@i-2000.com]
Sent: Tuesday, July 10, 2001 8:35 AM
To: struts-dev@jakarta.apache.org; Matthias.Bauer@livinglogic.de
Subject: Re: ActionMapping Workflows
Can I ask how you all are thinking about bouncing around between steps in
the workflow? Is it a stack that each step gets popped off? Arent workflow
steps cyclical sometimes? Developers talk alot about graphing workflows but
I have not read about the implementation.
----- Original Message -----
From: "Matthias Bauer" <Ma...@livinglogic.de>
To: <st...@jakarta.apache.org>
Sent: Tuesday, July 10, 2001 9:12 AM
Subject: Re: ActionMapping Workflows
> Ok, that's fine with me and it makes pretty much sense. However, this will
not
> be enough to implement workflow completely. It is just a little step
toward
> workflow control as a whole, just the same as the simple workflow
extension I
> already proposed together with some code on this list.
>
> I think all this should be put together to come up with a reasonable
concept how
> to implement workflow, instead of multiple single efforts to implement
some
> single aspects only.
>
> Is there a team working on that?
>
> --- Matthias
>
>
>
> Ted Husted wrote:
>
> > I suppose storing the information in the session would work. Though, I
> > imagine this means the state value would be hardcoded into the Java
> > source. I'm working toward scripting workflows from within the
> > ActionMappings, and would like to be able to reroute the flow without
> > changing the Java source.
> >
> > The insert/update flow is one example. Another would be inserting one
> > record and stopping, or inserting one record type and then another type
> > (and another type). Like say, creating a new vendor account, and then a
> > contact record for the account, and then a new stock item for the
> > account. With a dynamic action path, you can script something like this
> > from the ActionMappings alone, without modifying the JSPs or Java
> > source.
> >
> > I'm also now thinking that, given a dynamic action path, the best place
> > to represent it may be the ActionForward after all. This would change
> > the struts-config in my last post to:
> >
> > <action ...>
> > <forward
> > name="continue"
> > path="/WEB-INF/pages/script/Form.jsp"
> > request="true"
> > actionPath="/script/Insert"/>
> > </action>
> >
> > which supports the idea of having an Action return various logical
> > forwards, which could map to various forms, and being able to program
> > where those forms submit back to, all from within the ActionMappings.
> >
> > Matthias Bauer wrote:
> >
> >>In the actions DisplayInsertAction or DisplayUpdateAction respectively,
I store
> >>a state value in session scope which is checked in ProcessAction and
upon with I
> >>decide whether to do an update or insert.
> >>
> >>With this pattern I do not really see the necessity to dynamically set
the
> >>action attribute in forms.
> >>
> >>Do I miss something?
> >>
> >>--- Matthias
> >>
> >>Ted Husted wrote:
> >>
> >>
> >>>The general idea I'm playing with now is
> >>>
> >>>1) Extend ActionMappings with "request" and "actionPath" properties.
> >>>
> >>>2) Extend ActionServlet to place the ActionMapping in the request
> >>>context if request=true.
> >>>
> >>>3) Extend html:form to check for ActionMapping.getActionPath() when the
> >>>path is not specified.
> >>>
> >>>So in struts-config you could specify
> >>>
> >>>request="true"
> >>>actionPath="/insertAction"
> >>>parameter="insert"
> >>>
> >>>or
> >>>
> >>>request="true"
> >>>actionPath="/updateAction"
> >>>parameter="update"
> >>>
> >>>and have the appropriate path automagically appear in your html:form.
> >>>The Action can then call getParameter() to determine whether it's
> >>>suppose to insert or update the ActionForm data. Viola, no hidden
> >>>fields!
> >>>
>
>
>
Re: ActionMapping Workflows
Posted by Jonathan <ja...@i-2000.com>.
Can I ask how you all are thinking about bouncing around between steps in
the workflow? Is it a stack that each step gets popped off? Arent workflow
steps cyclical sometimes? Developers talk alot about graphing workflows but
I have not read about the implementation.
----- Original Message -----
From: "Matthias Bauer" <Ma...@livinglogic.de>
To: <st...@jakarta.apache.org>
Sent: Tuesday, July 10, 2001 9:12 AM
Subject: Re: ActionMapping Workflows
> Ok, that's fine with me and it makes pretty much sense. However, this will
not
> be enough to implement workflow completely. It is just a little step
toward
> workflow control as a whole, just the same as the simple workflow
extension I
> already proposed together with some code on this list.
>
> I think all this should be put together to come up with a reasonable
concept how
> to implement workflow, instead of multiple single efforts to implement
some
> single aspects only.
>
> Is there a team working on that?
>
> --- Matthias
>
>
>
> Ted Husted wrote:
>
> > I suppose storing the information in the session would work. Though, I
> > imagine this means the state value would be hardcoded into the Java
> > source. I'm working toward scripting workflows from within the
> > ActionMappings, and would like to be able to reroute the flow without
> > changing the Java source.
> >
> > The insert/update flow is one example. Another would be inserting one
> > record and stopping, or inserting one record type and then another type
> > (and another type). Like say, creating a new vendor account, and then a
> > contact record for the account, and then a new stock item for the
> > account. With a dynamic action path, you can script something like this
> > from the ActionMappings alone, without modifying the JSPs or Java
> > source.
> >
> > I'm also now thinking that, given a dynamic action path, the best place
> > to represent it may be the ActionForward after all. This would change
> > the struts-config in my last post to:
> >
> > <action ...>
> > <forward
> > name="continue"
> > path="/WEB-INF/pages/script/Form.jsp"
> > request="true"
> > actionPath="/script/Insert"/>
> > </action>
> >
> > which supports the idea of having an Action return various logical
> > forwards, which could map to various forms, and being able to program
> > where those forms submit back to, all from within the ActionMappings.
> >
> > Matthias Bauer wrote:
> >
> >>In the actions DisplayInsertAction or DisplayUpdateAction respectively,
I store
> >>a state value in session scope which is checked in ProcessAction and
upon with I
> >>decide whether to do an update or insert.
> >>
> >>With this pattern I do not really see the necessity to dynamically set
the
> >>action attribute in forms.
> >>
> >>Do I miss something?
> >>
> >>--- Matthias
> >>
> >>Ted Husted wrote:
> >>
> >>
> >>>The general idea I'm playing with now is
> >>>
> >>>1) Extend ActionMappings with "request" and "actionPath" properties.
> >>>
> >>>2) Extend ActionServlet to place the ActionMapping in the request
> >>>context if request=true.
> >>>
> >>>3) Extend html:form to check for ActionMapping.getActionPath() when the
> >>>path is not specified.
> >>>
> >>>So in struts-config you could specify
> >>>
> >>>request="true"
> >>>actionPath="/insertAction"
> >>>parameter="insert"
> >>>
> >>>or
> >>>
> >>>request="true"
> >>>actionPath="/updateAction"
> >>>parameter="update"
> >>>
> >>>and have the appropriate path automagically appear in your html:form.
> >>>The Action can then call getParameter() to determine whether it's
> >>>suppose to insert or update the ActionForm data. Viola, no hidden
> >>>fields!
> >>>
>
>
>
Re: ActionMapping Workflows
Posted by Matthias Bauer <Ma...@livinglogic.de>.
Ok, that's fine with me and it makes pretty much sense. However, this will not
be enough to implement workflow completely. It is just a little step toward
workflow control as a whole, just the same as the simple workflow extension I
already proposed together with some code on this list.
I think all this should be put together to come up with a reasonable concept how
to implement workflow, instead of multiple single efforts to implement some
single aspects only.
Is there a team working on that?
--- Matthias
Ted Husted wrote:
> I suppose storing the information in the session would work. Though, I
> imagine this means the state value would be hardcoded into the Java
> source. I'm working toward scripting workflows from within the
> ActionMappings, and would like to be able to reroute the flow without
> changing the Java source.
>
> The insert/update flow is one example. Another would be inserting one
> record and stopping, or inserting one record type and then another type
> (and another type). Like say, creating a new vendor account, and then a
> contact record for the account, and then a new stock item for the
> account. With a dynamic action path, you can script something like this
> from the ActionMappings alone, without modifying the JSPs or Java
> source.
>
> I'm also now thinking that, given a dynamic action path, the best place
> to represent it may be the ActionForward after all. This would change
> the struts-config in my last post to:
>
> <action ...>
> <forward
> name="continue"
> path="/WEB-INF/pages/script/Form.jsp"
> request="true"
> actionPath="/script/Insert"/>
> </action>
>
> which supports the idea of having an Action return various logical
> forwards, which could map to various forms, and being able to program
> where those forms submit back to, all from within the ActionMappings.
>
> Matthias Bauer wrote:
>
>>In the actions DisplayInsertAction or DisplayUpdateAction respectively, I store
>>a state value in session scope which is checked in ProcessAction and upon with I
>>decide whether to do an update or insert.
>>
>>With this pattern I do not really see the necessity to dynamically set the
>>action attribute in forms.
>>
>>Do I miss something?
>>
>>--- Matthias
>>
>>Ted Husted wrote:
>>
>>
>>>The general idea I'm playing with now is
>>>
>>>1) Extend ActionMappings with "request" and "actionPath" properties.
>>>
>>>2) Extend ActionServlet to place the ActionMapping in the request
>>>context if request=true.
>>>
>>>3) Extend html:form to check for ActionMapping.getActionPath() when the
>>>path is not specified.
>>>
>>>So in struts-config you could specify
>>>
>>>request="true"
>>>actionPath="/insertAction"
>>>parameter="insert"
>>>
>>>or
>>>
>>>request="true"
>>>actionPath="/updateAction"
>>>parameter="update"
>>>
>>>and have the appropriate path automagically appear in your html:form.
>>>The Action can then call getParameter() to determine whether it's
>>>suppose to insert or update the ActionForm data. Viola, no hidden
>>>fields!
>>>
Re: ActionMapping Workflows
Posted by Ted Husted <hu...@apache.org>.
I suppose storing the information in the session would work. Though, I
imagine this means the state value would be hardcoded into the Java
source. I'm working toward scripting workflows from within the
ActionMappings, and would like to be able to reroute the flow without
changing the Java source.
The insert/update flow is one example. Another would be inserting one
record and stopping, or inserting one record type and then another type
(and another type). Like say, creating a new vendor account, and then a
contact record for the account, and then a new stock item for the
account. With a dynamic action path, you can script something like this
from the ActionMappings alone, without modifying the JSPs or Java
source.
I'm also now thinking that, given a dynamic action path, the best place
to represent it may be the ActionForward after all. This would change
the struts-config in my last post to:
<action ...>
<forward
name="continue"
path="/WEB-INF/pages/script/Form.jsp"
request="true"
actionPath="/script/Insert"/>
</action>
which supports the idea of having an Action return various logical
forwards, which could map to various forms, and being able to program
where those forms submit back to, all from within the ActionMappings.
Matthias Bauer wrote:
> In the actions DisplayInsertAction or DisplayUpdateAction respectively, I store
> a state value in session scope which is checked in ProcessAction and upon with I
> decide whether to do an update or insert.
>
> With this pattern I do not really see the necessity to dynamically set the
> action attribute in forms.
>
> Do I miss something?
>
> --- Matthias
>
> Ted Husted wrote:
>
> > The general idea I'm playing with now is
> >
> > 1) Extend ActionMappings with "request" and "actionPath" properties.
> >
> > 2) Extend ActionServlet to place the ActionMapping in the request
> > context if request=true.
> >
> > 3) Extend html:form to check for ActionMapping.getActionPath() when the
> > path is not specified.
> >
> > So in struts-config you could specify
> >
> > request="true"
> > actionPath="/insertAction"
> > parameter="insert"
> >
> > or
> >
> > request="true"
> > actionPath="/updateAction"
> > parameter="update"
> >
> > and have the appropriate path automagically appear in your html:form.
> > The Action can then call getParameter() to determine whether it's
> > suppose to insert or update the ActionForm data. Viola, no hidden
> > fields!
Re: ActionMapping Workflows
Posted by Matthias Bauer <Ma...@livinglogic.de>.
Ted and others,
I don't really see the necessity of this extension for your update/insert scenario.
What you want to do is the following:
Insert: -> InsertAction
/
ActionForm
\
Update: -> UpdateAction
Now your problem is, how to specify the right action attribute in ActionForm, right?
Whenever I had a problem like that I did the following:
Insert: DisplayInsertAction
\
-> ActionForm - > ProcessAction
/
Update: DisplayUpdateAction
In the actions DisplayInsertAction or DisplayUpdateAction respectively, I store
a state value in session scope which is checked in ProcessAction and upon with I
decide whether to do an update or insert.
With this pattern I do not really see the necessity to dynamically set the
action attribute in forms.
Do I miss something?
--- Matthias
Ted Husted wrote:
> The general idea I'm playing with now is
>
> 1) Extend ActionMappings with "request" and "actionPath" properties.
>
> 2) Extend ActionServlet to place the ActionMapping in the request
> context if request=true.
>
> 3) Extend html:form to check for ActionMapping.getActionPath() when the
> path is not specified.
>
> So in struts-config you could specify
>
> request="true"
> actionPath="/insertAction"
> parameter="insert"
>
> or
>
> request="true"
> actionPath="/updateAction"
> parameter="update"
>
> and have the appropriate path automagically appear in your html:form.
> The Action can then call getParameter() to determine whether it's
> suppose to insert or update the ActionForm data. Viola, no hidden
> fields!
>
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
>
> Chuck Stern wrote:
>
>>I think this is a great idea. I can't tell you how many times I've
>>dynamically loaded hidden fields to determine the "nextAction". A standard
>>way of doing this would be very nice.
>>
>>Chuck
>>
Re: ActionMapping Workflows
Posted by Ted Husted <hu...@apache.org>.
The general idea I'm playing with now is
1) Extend ActionMappings with "request" and "actionPath" properties.
2) Extend ActionServlet to place the ActionMapping in the request
context if request=true.
3) Extend html:form to check for ActionMapping.getActionPath() when the
path is not specified.
So in struts-config you could specify
request="true"
actionPath="/insertAction"
parameter="insert"
or
request="true"
actionPath="/updateAction"
parameter="update"
and have the appropriate path automagically appear in your html:form.
The Action can then call getParameter() to determine whether it's
suppose to insert or update the ActionForm data. Viola, no hidden
fields!
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Chuck Stern wrote:
>
> I think this is a great idea. I can't tell you how many times I've
> dynamically loaded hidden fields to determine the "nextAction". A standard
> way of doing this would be very nice.
>
> Chuck
RE: ActionMapping Workflows
Posted by Chuck Stern <cs...@safenetconsulting.com>.
I think this is a great idea. I can't tell you how many times I've
dynamically loaded hidden fields to determine the "nextAction". A standard
way of doing this would be very nice.
Chuck
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Monday, July 09, 2001 4:44 PM
To: struts-dev@jakarta.apache.org
Subject: ActionMapping Workflows
"Craig R. McClanahan" wrote:
> One fairly radical idea I've considered is to not use events for this
> purpose, but to treat the basic processing that the controller servlet
> itself does as a workflow that can be scripted. That way, you could (in
> effect) insert your own "processXxxx" type functions anyplace you like in
> the standard workflow. Presumably, the scripting language for the
> workflow would have mechanisms to support conditional processing to deal
> with my question above.
Which reminds me of another idea -- using the ActionMappings to script
workflows.
Something many of us do is put the basic data-entry ActionForm to
multiple purposes. For example to both insert and update a record.
Often, you may also want to enter several types of records in a series.
For example, when creating a new vendor you may also want to go on and
create a new stock item for that vendor. Other times, you may just want
to enter a new stock item for an existing vendor.
With the ActionMappings, it's not hard to chain actions together. If
each action is returning a common token, like "success" or "continue",
it's trivial to setup another mapping that would send the actor on to
the create item form after creating a vendor.
But, since the action path in an ActionForm is usually hardcoded,
implementing this means doing fancy things with hidden fields and
revealing a bit too much about the application flow in the view.
One workaround is to leverage that the path property to html:form
accepts runtime properties, which means you can pass the action path in
the request context using a (ugh!) JSP expression, like this:
<html:form action="<%=(String) request.getAttribute("ACTION_PATH")%>">
given a String property set to the appropriate URI.
This can lead to an Action Mapping like this for an input-and-insert
flow:
<action
path="/script/Input"
type="org.wxxi.gavel.script.http.Access"
...
parameter="input">
<forward
name="continue"
path="/WEB-INF/pages/script/Form.jsp"/>
<forward
name="action.path"
path="/script/Insert"/>
which says forward to the Form.jsp and then submit it to /script/Insert
and like this for a select-and-update flow:
<action
path="/script/Select"
type="org.wxxi.gavel.script.http.Access"
...
parameter="select">
>
<forward
name="continue"
path="/WEB-INF/pages/script/Form.jsp"/>
<forward
name="action.path"
path="/script/Update"/>
</action>
which says forward to the same Form.jsp but this time submit it to
/script/Update
In the Action (there's only one for all of these), you can do this to
send the action path to the form:
// -- Set Action Path
String action_path = null;
ActionForward actionForward = mapping.findForward("action.path");
// Default to self if no override
if (actionForward==null) action_path = mapping.getPath();
else action_path = actionForward.getPath();
request.setAttribute("ACTION_PATH",action_path);
which brings us back to
<html:form action="<%=(String) request.getAttribute("ACTION_PATH")%>">
Again, one of the very nice things about using a dynamic path with an
ActionForm is that it can avoid embedding hidden fields in the view, and
moves control over what goes where into the ActionMappings. What I've
been doing is passing what would usually be the hidden field as the
generic ActionMapping parameter property, and using that to call
whatever action task (insert, update, delete, et cetera) is needed.
Along with Matthias's suggestions about extending the ActionMappings for
authentification, I wondered if there were any interest in extending
them for other workflow issues as well.
I'm also wondering if anyone else is interested in having dynamic paths
for ActionForms, and whether we want to build this into the framework or
not.
-Ted.
ActionMapping Workflows
Posted by Ted Husted <hu...@apache.org>.
"Craig R. McClanahan" wrote:
> One fairly radical idea I've considered is to not use events for this
> purpose, but to treat the basic processing that the controller servlet
> itself does as a workflow that can be scripted. That way, you could (in
> effect) insert your own "processXxxx" type functions anyplace you like in
> the standard workflow. Presumably, the scripting language for the
> workflow would have mechanisms to support conditional processing to deal
> with my question above.
Which reminds me of another idea -- using the ActionMappings to script
workflows.
Something many of us do is put the basic data-entry ActionForm to
multiple purposes. For example to both insert and update a record.
Often, you may also want to enter several types of records in a series.
For example, when creating a new vendor you may also want to go on and
create a new stock item for that vendor. Other times, you may just want
to enter a new stock item for an existing vendor.
With the ActionMappings, it's not hard to chain actions together. If
each action is returning a common token, like "success" or "continue",
it's trivial to setup another mapping that would send the actor on to
the create item form after creating a vendor.
But, since the action path in an ActionForm is usually hardcoded,
implementing this means doing fancy things with hidden fields and
revealing a bit too much about the application flow in the view.
One workaround is to leverage that the path property to html:form
accepts runtime properties, which means you can pass the action path in
the request context using a (ugh!) JSP expression, like this:
<html:form action="<%=(String) request.getAttribute("ACTION_PATH")%>">
given a String property set to the appropriate URI.
This can lead to an Action Mapping like this for an input-and-insert
flow:
<action
path="/script/Input"
type="org.wxxi.gavel.script.http.Access"
...
parameter="input">
<forward
name="continue"
path="/WEB-INF/pages/script/Form.jsp"/>
<forward
name="action.path"
path="/script/Insert"/>
which says forward to the Form.jsp and then submit it to /script/Insert
and like this for a select-and-update flow:
<action
path="/script/Select"
type="org.wxxi.gavel.script.http.Access"
...
parameter="select">
>
<forward
name="continue"
path="/WEB-INF/pages/script/Form.jsp"/>
<forward
name="action.path"
path="/script/Update"/>
</action>
which says forward to the same Form.jsp but this time submit it to
/script/Update
In the Action (there's only one for all of these), you can do this to
send the action path to the form:
// -- Set Action Path
String action_path = null;
ActionForward actionForward = mapping.findForward("action.path");
// Default to self if no override
if (actionForward==null) action_path = mapping.getPath();
else action_path = actionForward.getPath();
request.setAttribute("ACTION_PATH",action_path);
which brings us back to
<html:form action="<%=(String) request.getAttribute("ACTION_PATH")%>">
Again, one of the very nice things about using a dynamic path with an
ActionForm is that it can avoid embedding hidden fields in the view, and
moves control over what goes where into the ActionMappings. What I've
been doing is passing what would usually be the hidden field as the
generic ActionMapping parameter property, and using that to call
whatever action task (insert, update, delete, et cetera) is needed.
Along with Matthias's suggestions about extending the ActionMappings for
authentification, I wondered if there were any interest in extending
them for other workflow issues as well.
I'm also wondering if anyone else is interested in having dynamic paths
for ActionForms, and whether we want to build this into the framework or
not.
-Ted.
Re: About extensons support mechanism...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 7 Jul 2001, Martin Cooper wrote:
> > Is what I describe above within the scope of the event/listener
> > todo for 1.1? I thought it might be, which is why I said
> > I was interested in tying the Extensions package into
> > the event/listener model work.
>
> I think this is a perfect candidate for the event/listener framework. The
> key is to decide what the interesting events are. This needs to be done
> outside the context of the current implementation as much as possible.
>
I think the two concepts are related as well. "Extensions" would be a
perfectly natural way to configure your listeners.
> What I mean by that is that we should not be looking at the code and saying
> "oh, there's an interesting method I'd like to hook into" so much as
> thinking "ah, it would be interesting to be told when this is about to
> happen or that has finished happening". If the code ends up needing some
> restructuring to accommodate that, then we should go ahead and make those
> changes.
>
> If we only look at the current implementation, then we will be looking with
> blinders on. There is a much greater risk that we will hinder the
> development of later extensions, by looking at what we have instead of
> thinking about what we really want.
>
Another issue (and, frankly, the reason that I didn't include an
event/listener model earlier) is more complex -- what if a listener wants
to *modify* what happens next? For example, let's say you wanted to
implement "is the user logged on?" checking as an event listener. How
would the listener indicate back to the framework that the request should
be redirected to the logon page?
One fairly radical idea I've considered is to not use events for this
purpose, but to treat the basic processing that the controller servlet
itself does as a workflow that can be scripted. That way, you could (in
effect) insert your own "processXxxx" type functions anyplace you like in
the standard workflow. Presumably, the scripting language for the
workflow would have mechanisms to support conditional processing to deal
with my question above.
Given that, an event/listener model that merely notifies application logic
about things that are happening is still useful -- it's just not going to
be called on to serve this purpose.
> --
> Martin Cooper
>
Craig
Re: About extensons support mechanism...
Posted by Martin Cooper <ma...@tumbleweed.com>.
> Is what I describe above within the scope of the event/listener
> todo for 1.1? I thought it might be, which is why I said
> I was interested in tying the Extensions package into
> the event/listener model work.
I think this is a perfect candidate for the event/listener framework. The
key is to decide what the interesting events are. This needs to be done
outside the context of the current implementation as much as possible.
What I mean by that is that we should not be looking at the code and saying
"oh, there's an interesting method I'd like to hook into" so much as
thinking "ah, it would be interesting to be told when this is about to
happen or that has finished happening". If the code ends up needing some
restructuring to accommodate that, then we should go ahead and make those
changes.
If we only look at the current implementation, then we will be looking with
blinders on. There is a much greater risk that we will hinder the
development of later extensions, by looking at what we have instead of
thinking about what we really want.
--
Martin Cooper
----- Original Message -----
From: "Ron Smith" <ro...@rpsenterprises.com>
To: <st...@jakarta.apache.org>
Sent: Wednesday, July 04, 2001 6:18 AM
Subject: Re: About extensons support mechanism...
>
> When I created the ExtensionsServlet (I assume ServicesServlet
> takes its place here), I stopped short after the
> init(), destroy(), and initDigester() methods because I had
> a feeling that we might want to handle extending the other
> methods using a different mechanism.
> I see init, destroy, and initDigester methods as basic
> lifecycle methods that most/all extensions/services would want
> to tap into.
> When getting into the process() type of methods, I could see
> many extensions would want to tap into one or more of these methods,
> but why limit it to the ActionServlet class? An extension may want
> to be able to tap into points in processing of other classes, such
> as an action class or forward class. From looking at the code it seems
> like most processing is going on in the ActionServlet, but
> my gut feel is that some extensions will need to extend processing
> points in other classes besides ActionServlet - it's just one class
> in an application framework after all.
>
> For this, I think something like your second solution with a more
> centralized event dispatcher/queue would be needed. The listeners
> (services) would register interest in an event with a central
> dispatcher. When the ActionServlet (or whatever class is generating
> the events) gets to one of these points in processing, like
> processPopulateBefore(), it would fire off an event to the central
> dispatcher which would immediately notify the listeners registered
> for that event type.
> So the listeners are decoupled from the class generating the
> events (e.g. ActionServlet). Heck, the object generating the
> event doesn't even have to exist for the listener to be able to
> register interest in the event it generates (which is probably necessary
> to trap events from classes like Action and ActionForward).
>
> Is what I describe above within the scope of the event/listener
> todo for 1.1? I thought it might be, which is why I said
> I was interested in tying the Extensions package into
> the event/listener model work.
>
> So my two cents is I'd like to generalize the listener/event/dispatch
> mechanism and to support listening to classes beyond ActionServlet.
>
>
> Oleg V Alexeev wrote:
> >
> > Hello struts-dev,
> >
> > This evening I end up druft of ServicesServlet - extended version of
> > ActionServlet with support of pluggable services (extensions in old
> > terms). I puzzle over architectural question about ServicesServlet
> > and may be anybody can suggest me right way...
> >
> > ServiceServlet work on idea - developer can register unlimited
> > number of services in struts-config, each service is a java class
> > based on Service interface, each service can be subscribed to any
> > processing point, such as - init, destroy, initDigester,
> > processPreprocess, processPopulateBefore, processPopulateAfter,
> > processValidateBefore, processValidateAfter. ServiceServlet iterate
> > via list of subscriptions at every processing point and call
> > appropriate method from service.
> >
> > My question is - what way is the best to serve processing points
> > listed above? Now I create FastArrayList instances for every
> > subscription list and all manipulations with subscriptions
> > (register, get iterator via subscriptions, drop, etc.) are made with
> > help of separate method -
> >
> > registerInitMember( Service service, int order ) {}
> > regisetrInitDigesterMember( Service service, int order ) {}
> > ....
> >
> > May be such solution would be more flexible? -
> > registerMember( Service service, int order, String pointName ) {
> > //find ArrayList of subscriptions for such pointName
> > //register service at ArrayList
> > }
> >
> > Hard coded solution is more reliable, but time consume and not
> > flexible. But more flexible solution, with search for appropriate
> > subscription, is slow for my mind. What way is the best?
> >
> >
> > --
> > Best regards,
> > Oleg mailto:gonza@penza.net
>
Re: About extensons support mechanism...
Posted by Ron Smith <ro...@rpsenterprises.com>.
When I created the ExtensionsServlet (I assume ServicesServlet
takes its place here), I stopped short after the
init(), destroy(), and initDigester() methods because I had
a feeling that we might want to handle extending the other
methods using a different mechanism.
I see init, destroy, and initDigester methods as basic
lifecycle methods that most/all extensions/services would want
to tap into.
When getting into the process() type of methods, I could see
many extensions would want to tap into one or more of these methods,
but why limit it to the ActionServlet class? An extension may want
to be able to tap into points in processing of other classes, such
as an action class or forward class. From looking at the code it seems
like most processing is going on in the ActionServlet, but
my gut feel is that some extensions will need to extend processing
points in other classes besides ActionServlet - it's just one class
in an application framework after all.
For this, I think something like your second solution with a more
centralized event dispatcher/queue would be needed. The listeners
(services) would register interest in an event with a central
dispatcher. When the ActionServlet (or whatever class is generating
the events) gets to one of these points in processing, like
processPopulateBefore(), it would fire off an event to the central
dispatcher which would immediately notify the listeners registered
for that event type.
So the listeners are decoupled from the class generating the
events (e.g. ActionServlet). Heck, the object generating the
event doesn't even have to exist for the listener to be able to
register interest in the event it generates (which is probably necessary
to trap events from classes like Action and ActionForward).
Is what I describe above within the scope of the event/listener
todo for 1.1? I thought it might be, which is why I said
I was interested in tying the Extensions package into
the event/listener model work.
So my two cents is I'd like to generalize the listener/event/dispatch
mechanism and to support listening to classes beyond ActionServlet.
Oleg V Alexeev wrote:
>
> Hello struts-dev,
>
> This evening I end up druft of ServicesServlet - extended version of
> ActionServlet with support of pluggable services (extensions in old
> terms). I puzzle over architectural question about ServicesServlet
> and may be anybody can suggest me right way...
>
> ServiceServlet work on idea - developer can register unlimited
> number of services in struts-config, each service is a java class
> based on Service interface, each service can be subscribed to any
> processing point, such as - init, destroy, initDigester,
> processPreprocess, processPopulateBefore, processPopulateAfter,
> processValidateBefore, processValidateAfter. ServiceServlet iterate
> via list of subscriptions at every processing point and call
> appropriate method from service.
>
> My question is - what way is the best to serve processing points
> listed above? Now I create FastArrayList instances for every
> subscription list and all manipulations with subscriptions
> (register, get iterator via subscriptions, drop, etc.) are made with
> help of separate method -
>
> registerInitMember( Service service, int order ) {}
> regisetrInitDigesterMember( Service service, int order ) {}
> ....
>
> May be such solution would be more flexible? -
> registerMember( Service service, int order, String pointName ) {
> //find ArrayList of subscriptions for such pointName
> //register service at ArrayList
> }
>
> Hard coded solution is more reliable, but time consume and not
> flexible. But more flexible solution, with search for appropriate
> subscription, is slow for my mind. What way is the best?
>
>
> --
> Best regards,
> Oleg mailto:gonza@penza.net