I tried JBoss JBPM and it worked for complex compound workflows. It also had
a eclipse designer plugin that could save the workflow image and provided a
class that visualised the current workflow state.

It had persistence module that was based on Hibernate. I had just to
implement simple UI to present a user with workflows and tasks.

I believe user can stay unaware about how complex is the workflow and
whether it is compound.

Phil Housley wrote:
> Hello list,
> I'm currently working on some ideas for building apps with fairly
> complex workflows.  My aim is to find a nice pattern/framework for
> building apps where each unit of work involves many panels, several
> forms, lots of decisions and so on.  In particular I'm aiming at apps
> where you need to be very confident about exactly what is happening,
> so very strict control of actions, being careful of multiple
> renderings of a page each trying to change the server data, and so on.
>  Also, I'm wondering about some options for declarative building of
> workflows out of existing tasks.
> My current design involves running from a special page, which
> maintains a stack of tasks.  One type of task is a Workflow, which can
> be configured to automatically spawn subtasks as required, based on
> the result of previous tasks.  Another type of task is based on a
> panel, and is able to cause itself to be rendered.  The stack
> processor makes sure that each task is invoked at the right time, that
> a task can render if it is at the top of the stack, that only the top
> of the stack can be invoked from a form and so on.
> This is working ok for some silly demo cases, but there are various
> issues.  For example, any task that is not also a component cannot
> access dependency injection, or set error messages and so on.  I'm not
> sure how to get around this at the moment, as I don't want to force
> every task to be a component, when many will likely have no cause to
> ever be rendered.
> So, the reason I'm posting is to ask mainly two things:
> 1) Is this of interest to anyone else?  All the code is my own, so
> I'll open source it if there seems to be some future in it.
> 2) If so, does anyone have any comments on my current design?  Clearly
> there are problems with it, but should I carry on trying to find ways
> to work around them, or does the whole thing sounds like so much
> crack?
> Thanks,
> -- 
> Phil Housley
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org

View this message in context: 
Sent from the Wicket - User mailing list archive at Nabble.com.

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to