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:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 4:44 PM
To: [EMAIL PROTECTED]
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.
