Re: Complicated workflows

2009-09-30 Thread Phil Housley
2009/9/30 Igor Vaynberg igor.vaynb...@gmail.com:
 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

Although only one task panel is ever drawn at the time, that is
broadly similar to how I have it set up at the moment.  If a task is
also a panel, it can elect to have itself displayed, at which point it
will be embedded in the page and no stack processing will happen until
the panel says it is complete.  Any other type of task simply doesn't
have the option to display, although it may spawn a panel task, which
may ask to be displayed, and so on.

The issue is that business logic should really always be in non-UI
tasks for things I have in mind, which lack things like easily being
able to call this.error(...).  I believe you are right about not
forcing the issue, so I'm currently thinking I will have to step up
the infrastructure to add things like error reporting.  Fortunately I
can just delegate to Wicket pretty quickly, so shouldn't be too much
extra code.

Phil.

 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



Re: Complicated workflows

2009-09-30 Thread Phil Housley
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.comwrote:

 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



Re: Complicated workflows

2009-09-30 Thread Vladimir K

I tried JBoss JBPM and it worked for complex compound workflows. It also had
a eclipse designer plugin that could save the workflow image and provided a
class that visualised the current workflow state.

It had persistence module that was based on Hibernate. I had just to
implement simple UI to present a user with workflows and tasks.

I believe user can stay unaware about how complex is the workflow and
whether it is compound.


Phil Housley 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
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Complicated-workflows-tp25671027p25682285.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Complicated workflows

2009-09-30 Thread Randy S.
We are also trying to find the right balance of how much we move to
declarative. It will depend on how well we get Web Flow to fit in.  With
Wicket being Controller-less and wanting to launch right into the home
page, Web Flow is a clear candidate to do initial data load and logic to
determine the first page. With Wicket out of the box, it seems that the
app's home page would need to have this conditional logic which could
include different panels or redirect depending on state. But that doesn't
seem very elegant. Also, because we run in very large clusters, redirects
are out of the question due to the potential that the second request hits a
different server before HTTP session has been properly persisted/shared.


On Wed, Sep 30, 2009 at 1:51 AM, Phil Housley undeconstruc...@gmail.comwrote:

 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 

RE: Complicated workflows

2009-09-30 Thread Chris Colman
 Also, because we run in very large clusters, redirects
 are out of the question due to the potential that the second request
hits
 a different server before HTTP session has been properly
persisted/shared.

Can't you set up server affinity for the cluster to avoid that from
occurring?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: RE: Complicated workflows

2009-09-30 Thread Randy S.
We use server affinity but you can't guarantee same server and I can't go in
with a 100% plan. We have had funny routing in some cases where requests
from the same user even bounce from one data center to another... and back.
We've done a lot of work to prevent these things but in the end it's never
guaranteed.

On the other hand, the chances of two back-to-back requests (as in the case
of a redirect) being routed to the same node are extremely high.

On Sep 30, 2009 9:58 PM, Chris Colman chr...@stepaheadsoftware.com
wrote:

 Also, because we run in very large clusters, redirects  are out of the
question due to the potent...
Can't you set up server affinity for the cluster to avoid that from
occurring?

- To
unsubscribe, e-mail: users...


Complicated workflows

2009-09-29 Thread Phil Housley
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



Re: Complicated workflows

2009-09-29 Thread Dane Laverty
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



Re: Complicated workflows

2009-09-29 Thread Scott Swank
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've gone that route with reasonable luck.  Of course I know precious
little about your specific application...

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



Re: Complicated workflows

2009-09-29 Thread Phil Housley
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



Re: Complicated workflows

2009-09-29 Thread Igor Vaynberg
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



Re: Complicated workflows

2009-09-29 Thread Randy S.
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.



On Tue, Sep 29, 2009 at 4:11 PM, Phil Housley undeconstruc...@gmail.comwrote:

 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