cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Piroumian <KPiroum...@protek.com>
Subject RE: continuation fear (was Re: [status & RT] design challenges)
Date Tue, 09 Apr 2002 08:34:17 GMT
> From: Ovidiu Predescu [mailto:ovidiu@apache.org] 
> On Mon, 08 Apr 2002 17:38:48 -0800, Rob Jellinghaus 
> <robj@unrealities.com> wrote:
> 
> > At 10:25 AM 4/7/2002 -0500, Ivelin Ivanov wrote:
> > >From: "Ovidiu Predescu" <ovidiu@apache.org>
> > >To: "Ivelin Ivanov" <ivelin@apache.org>
> > >Sent: Friday, April 05, 2002 10:33 PM
> > > > Workflow's approach appears to be based on a finite 
> state machine 
> > > > model. Checkout the sample control file at:
> > > >
> > 
> >http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/workflow/src/wi
> > >zard-de
> > >mo/WEB-INF/wizard.xml?rev=1.1&content-type=text/vnd.viewcvs-markup
> > > >
> > > > The same approach can be modeled in Cocoon today using actions.
> > 
> > Does anyone have an example of this?  The current action 
> example (the
> > standard sample webapp) is fairly sketchy, and it's not 
> clear how to do a 
> > more complex workflow.
> 
> I don't think you'll find such an explicit example today.

As a state-machine approach advocate I can say that we've developed a flow
controller with XML script and used it for rather complex workflows, e.g.
customer registration for a mobile operator, product selling and some
others. If anybody is interested then I can send a sample of the flow script
and describe the whole approach in details.

> 
> > > > However a much better approach is the one based on 
> continuations. 
> > > > Check out the Schecoon calculator sample at:
> > >
> > >I have actually seen it and was hoping that you can 
> elaborate a bit 
> > >on the advantages of continuations vs. state machine.
> > 
> > I agree.  Also, I'm fairly concerned by two things:
> > 
> > 1) Continuations are notoriously difficult to understand; building 
> > them as
> > the fundamental (and, if I understand Stefano's 
> predilections, *only!*) 
> > mechanism of webapp flow control is going to do some damage 
> to Cocoon's 
> > comprehensibility.
> 
> In Schecoon you don't deal with continuations directly, 
> they're hidden under the cover. The only thing you see is a 
> sendPage() function, which sends the response page and 
> interrupts the processing, only to resume it later when the 
> following request comes along.

What if you don't need to continue processing from an old position? Say, the
user passed several steps in wizard and that resulted in some business
calls. Returning back to one of the previous state would require a either an
intelligent rollback of operations or an error message telling that the user
cannot go back. With our XML flow approach each of this situations can be
handled on developer's discretion. 

> 
> > 2) Continuations are difficult to evaluate for performance.
> 
> This is a correct statement.
> 
> > A procedural model, with explicit webapp state management, at least 
> > makes it clear to the programmer how much state is being 
> kept by their 
> > webapp, and gives them more or less full control over tuning that 
> > state.  A continuation mechanism could radically change the 
> amount of 
> > retained state (consider the possibility of inadvertent variable 
> > capture of large data structures by a continuation stack!). And it 
> > might or might not be *possible* for the end programmer to 
> fix those 
> > capture issues.
> 
> I hope the rules that define what gets into a continuation 
> and what not, will be very clearly documented. It should be 
> simple for the end user programmer to fix these issues by 
> assigning these variables the null value before capturing a 
> continuation.
> 
> I'm also investigating some optimizations in the Rhino 
> implementation, that could eliminate capturing temporary 
> variables in continuations.
> 
> > Perhaps Ovidiu's proposed uses of continuations are elegant 
> enough, or 
> > the
> > current scripting/continuation-capture mechanism is 
> efficient and minimal 
> > enough, to address both these concerns.
> 
> The usage of the framework is fairly simple, and the notion 
> of continuation is not exposed explicitly when you're doing 
> programming as end user programmer.

In some cases one would like to handle continuation explicitly. Is it
possible now?

> 
> The scripting languages supported should know how to deal 
> with continuations explicitly, Schecoon/Cocoon cannot help in 
> any way in how they implement things.
> 
> > But personally I would very much hope that the flowmap mechanism 
> > allows (not requires, but allows) a more procedural style as well, 
> > with explicit state management.
> 
> My original Scheme-based implementation had continuations 
> support only, and no actions support was planned. The second 
> implementation, which is the current one, is much more 
> tightly coupled with Cocoon, so you can make use of all the 
> other features you're used to from Cocoon.
> 
> > You do not need to listen to me very closely, however, as I 
> am under 
> > enough time pressure with my current project (constructing a fairly 
> > complex multi-page form-based issue tracking system) to drive me to 
> > work with Struts instead.  It's a shame, as Cocoon seems 
> more like the 
> > right thing, but I don't have time to struggle with the 
> documentation 
> > (or lack thereof), or to wait for Schecoon to mature into something 
> > straightforwards.  I hope this changes in the very near 
> future (i.e. I 
> > hope Cocoon/Schecoon get better documentation & examples, or I get 
> > more time, or both :-)

Cocoon still loses users and it's very sad ;(

> 
> I certainly hope Cocoon will change for the better in the 
> very near future.

And we will do our best for that. One of the things that will make this
happen is to develop more real world samples and applications. One of the
reasons why Struts is more popular it's availabilty of good sample
applications and best practices documents.

Regards,
  Konstantin Piroumian
kpiroumian@protek.com

> 
> Greetings,
> -- 
> Ovidiu Predescu <ovidiu@apache.org> 
> http://www.geocities.com/SiliconValley/Monitor/7464/ > (GNU, 
> Emacs, other stuff)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message