Actually, I have looked at the workflow piece in commons and do like the way
it is going. Having worked a good deal with Weblogic BPM (Business Process
Integrator) and Tibco Active Enterprise, I do have some to contribute to
that package. However, I have a more struts specific idea in mind. One that
is targeted directly at web applications. I am working on an idea that I
call pageflow which would allow the connectivity of multiple pages in a
single "flow". It is essentially an upgraded controller architecture,
targeted at making the development of mini-flows in web apps easier. It is
similar in nature to the wizard concept put forward in the current workflow
proposal for struts. However, my idea is to seperate out the "worker" part
of workflow, which is intended to get some actual business processing done
(this part would live in the commons workflow package), and the page
controller aspect of struts.
For example, in a recent project using struts, we had 6 different pages
which needed to be accessed under different context. If the user came from
page A and they had selected to transfer Record A then the save button on
page B was supposed to do one thing. If the user came from page C then the
save button was supposed to do another. We also had passive actions that
needed to be executed Event Style so that when the user finally got to page
D something would happen based on where they started. This was not easy to
accomplish given the current framework. First, there was no contextual
navigation or Actions. Second, no events, so page A, in the example could
not setup a listener for arrival at page D, etc. Thirdly we had huge amounts
of data that we had to store in the session per user, which wouldn't be
garbage collected until after the session closed, even if the user were
never going to access it again. One other problem we had was knowing at any
given time what the users context was. We had to develop a way to query the
web engine for variables in the session, request, and applicaiton levels.
Having had the same types of problems in multiple web apps, I came up with
the idea of pageflow.
Essentially, the idea is to create a page concept, similar to the current
forwards declaration in the config file. However these pages would function
differently based on context. These pages could then be connected in
multiple sub "pageflows" which would have their own a) navigation context,
b) events (there would be application level events as well), c) scoped
variable declaration and storage (again there would still be request,
session and application scopes) and d) ability to call back into a workflow
engine for complex tasks and e) "live" action links which would allow the
developer to declaratively switch the Action handler and Form clasess. This
would let us do all sorts of interesting things, but the clear benefits in
my mind are:
a) painless garbage collection of pageflow scope variables (read lower
overhead)
b) clear contextual information about a users location and direction
c) allow interesting additions like declaritively going to 2 web pages
(using window.open() javascript) based on a the current variable context
(we've actually had to do this many times in our apps)
d) much lower cost of development of sophisticated web apps (declarative
handling of this type of behavior would have saved at least a couple hundred
developer hours and ours was a simple application)
e) actions could be more fine-grained and more declarative as well. For
example a lot of Action I have seen have things like:
class SaveCityAction{
perform(...){
String subaction = request.getParameter("subaction");
if(subaction.equals("cityOnTheMainland")){ ... }
else if (subaction.equals("hawaii") { ... }
...
After a while this kind of code gets very hard to handle and you then have
to start switching out finer grained actions using javascript (set the html
action to "suchAndSuch.do")
f) ability to override behaviour at multiple levels (such as scoped error
handling)
g) ability to create a visual editor
The best way to think about the solution is as a flow chart where pages can
be connected to other pages using either plain Action classes or Activity
connectors (activities would be workflow calls to the commons package on the
backend). Each action would have associated input and output variables which
correspond to the variables coming off of a page (a dynamic Form if you
will) going into the Action and the variables going into the next page.
Anyway, that was kind of fast and furious, and probably sounds a little
jumbled. I can lay it out more elegantly for you, given more time. However,
having built entirely too many of these mosters (web apps), and having
implemented a basic version of this framework (outside of struts) for a
previous employer, I am convinced that developers would love this addition
to the framework.
Feel free to flame away...
Paul Smith
[EMAIL PROTECTED]
[EMAIL PROTECTED]
----- Original Message -----
From: "Martin Cooper" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, February 16, 2002 11:36 PM
Subject: Re: Workflow/Pageflow proposal
> The workflow proposal originally made here is currently being developed in
> Jakarta Commons. The goal is to make the workflow framework as generic as
> possible, and therefore independent of specific projects such as Struts,
> while making it simple to integrate with them.
>
> It would be great if you could take a look at what's going on in Commons
and
> perhaps contribute your work there in such a way that Struts users
(amongst
> others) could make use of the end result.
>
> Thanks!
>
> --
> Martin Cooper
>
>
> ----- Original Message -----
> From: "Paul Smith" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, February 15, 2002 1:24 PM
> Subject: Workflow/Pageflow proposal
>
>
> Ted,
>
> I have a design put together for a pretty significant upgrade to the
struts
> framework which would meet the needs of the workflow requirements. I have
> set up the struts framework and have started a build structure in the
> contrib folder on my local machine. However, this is a major change, and I
> was wondering if I should run it past the group first. I thought it up a
> year or two ago and just recently decided to graft it onto the struts
> framework instead of starting my own. I have read the workflow proposal on
> the web and believe that my design would meet and exceed it in a number of
> ways. So what do you think? Should I attempt to layout the design on paper
> for the group (probably take me a while), or build it and then show
> everybody?
>
> Thanks,
> Paul
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
