there is really no point in having your tasks be components. why not simply
repeatingview rv=..
for (task t:tasks) {
if (t.hasUIComponent()) {
rv.add(t.getUIComponent());
}
}
-igor
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
