Craig,
Your Workflow Proposal seems like a great start. Several of us have
played around with some workflow concepts on our current project but it
would be great to have something integrated into Struts.
We have a few concepts that weren't mentioned that we think are worth
considering:
- "bookmarkable" workflow steps: This means being able to
store all context related to a step in such a fashion that
the user can go back to that same the same state in the
workflow at a later time. Bookmarkability should be
optional (some steps may not make sense to be bookmarked)
and so it should be able to be indicated as such when
being defined.
- a workflow "history": keep a state of where the user is
and/or has been. Allow this state to be displayed as
breadcrumbs, a history list, or with another visual or
navigational representation. A tag to render this
information seems useful as well.
- workflows, especially scripted workflows, will often be
customized. The workflow configuration files should support the
ability to override a workflow definition - one possibility
would be to use a mechanism similar to a Java classpath. The
primary concern here is updating installations with new
versions of out-of-the-box workflows without overwriting any
customized versions of those workflows.
- when a workflow is started, it should be associated with a
context that is specific to that *instance* of the workflow.
This supports the ability for a single user to execute the
same workflow multiple times simultaneously. In a web UI, this
is usually associated with a user opening multiple
windows. This implies that a workflow must have some kind of
instance id to uniquely identify its context and also makes it
clear that some kind of garbage-collection capability is
needed for workflows.
- the workflow configuration files/interfaces should support
i18n especially for labels since the labels will likely
appear in UI menus.
- the ability to define pre- and post- conditions (inputs/outputs)
for workflow steps would aid in robusting such as ensuring valid
workflow definitions.
A few basic questions that we have:
- Can you give some more detail on your initial thoughts for the
Struts implementation? The types of questions I have are:
o Where do Actions fit in with workflows/activities in
general? Are they used entirely behind the scenes when you
write the XML for an activity? From the proposal
description, it sounds as if writing an Activity will not
require Struts coding... do this imply it will generate the
necessary Actions, etc?
o Would things like Actions, ActionForms, and JSP pages need
to be written so they are "workflow aware"?
o Are you thinking you'd extend ActionMappings to have another
layer where they can handle Activities or something else?
Here we're wondering if there's a way to retain the overall
model programming in Struts but allowing non-programmers to
create workflows.
- Do you think browser issues can be handled properly? Caching
has caused us problems in the areas of handling back, forward,
refresh buttons... for example, the previous page displays
correctly but the actual state of the workflow has not been
updated due to the page being cached and the context state is
incorrect.
thanks,
john sigler
