Phil,

Would an event-centric approach simplify things?  I'm thinking that
you could then have multiple listeners for a given event and the
various listeners would not have to be aware of one another.  This
might reduce the task/sub-task interactions.  Adding errors, or
refreshing components could be handled by various listeners as needed.

I've gone that route with reasonable luck.  Of course I know precious
little about your specific application...

Cheers,
Scott


On Tue, Sep 29, 2009 at 2:11 PM, Phil Housley <undeconstruc...@gmail.com> 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
>
>

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

Reply via email to