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:
InjectorHolder.getInjector().inject(this); 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 :) Dane 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