2009/9/30 Randy S. <randypo...@gmail.com>: > Have you thought about using Spring Web Flow for this? I'm not a SWF expert, > but it sounds like something well-tailored to your needs. For example, a > flow can have steps that don't have UIs. > > Our group at work is looking into Wicket & SWF integration. I have a seen a > few comments on the web from folks like Peter Thomas who conclude that you > don't need to use SWF with Wicket. We need to externalize the flow of some > applications so we have discussed shallow integration (where, for example, a > button.onClick explicitly calls SWF to determine what to do next), as well > as deep(er) integration (perhaps at the RequestCycleProcessor. At the > moment, we are leaning toward the shallow/lightweight integration which > gives lots of flexibility to each application to respond to a flow's > response in different ways (show a new page, update components via Ajax, > redirect to another URL, etc.). > > In case anyone is interested, reasons we need to externalize flow on some > apps are things like: Complex business rules, business unit authoring of > flow (via a controlled UI), and delegation to a business process manager > layer.
Actually, I hadn't realised that WebFlow wasn't limited to Spring MVC. Looking at it now, I am doing something fairly similar, so I probably ought to take a longer look... The reasons I started on this thing with code rather than going totally declarative is that my current experience is that there will be sufficient corner cases to make it necessary to regularly subclass actions or panels for a particular instance. Where that isn't required, I was thinking that a Spring context file would provide a nice declarative way of configuring everything, with prototype scope beans etc being well fitted to creating tasks. Despite all that, I don't particularly want a hard dependency on anything other than Wicket, so plain Java first, other things hopefully on top. Phil > On Tue, Sep 29, 2009 at 4: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