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

Reply via email to