If you're using Spring, the dependency injection issue for
non-component items can be solved by adding the following line to the
object's constructor:


where InjectorHolder is org.apache.wicket.injection.web.InjectorHolder
. I'm afraid I don't have any advice to offer you on the rest of it,
except that it sounds like a good work and I hope you can get it doing
what you need :)


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