2009/9/29 Scott Swank <scott.sw...@gmail.com>: > 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 did consider that route, but one of the things I most want is to be able to embed one workflow in another, so I can reuse common tasks - hence the stack where a workflow is just like another task. Having listeners doesn't make much sense, I felt, when adding a new task/workflow to the stack temporarily hides everything underneath. Currently there really isn't much interaction between sibling tasks, when the current task says it is complete, another task is prepared, possibly showing a panel, or maybe just running and completing immediately. Events are simulated by having a task return a code, and the wiring says what transition follows each code. e.g. Task 1, on "success" -> Task 2, on "failure" -> Task X > I've gone that route with reasonable luck. Of course I know precious > little about your specific application... Really there is no specific application, I'm just trying to solve a general problem. The inspiration is my day job, for which I wrote a tiny little workflow engine, which basically just gives some help switching panels around. I'm not allowed to do a version 2 there though, so I'm doing it off my own back at home. > 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 > > -- Phil Housley --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
