Re: RE: Complicated workflows
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" 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...
RE: Complicated workflows
> 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: Complicated workflows
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 wrote: > 2009/9/30 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. > > 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 >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 > > ---
Re: Complicated workflows
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/9/30 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. 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 > 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/9/30 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
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
> 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
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 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
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 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/9/29 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 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 > 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
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 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
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 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
