continuation fear (was Re: [status & RT] design challenges)

[Rob Jellinghaus <ro...@unrealities.com>]

At 10:25 AM 4/7/2002 -0500, Ivelin Ivanov wrote:
>From: "Ovidiu Predescu" <ov...@apache.org>
>To: "Ivelin Ivanov" <iv...@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/wizard-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.

> > 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.

2) Continuations are difficult to evaluate for performance.  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.

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.  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.

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 :-)

Cheers,
Rob



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

Re: continuation fear (was Re: [status & RT] design challenges)

[Ivelin Ivanov <iv...@apache.org>]

This Q&A should go to the FAQ.

I've bumped into Mikhail's scenario a few times already.
Struts is popular, proven to work, Cocoon is just too new and risky ...
talks.


And BTW, Struts main power is its elegant form handling tags.
Cocoon is still lacking on that arena, but things are changing fast... just
follow the list for news.


----- Original Message -----
From: "Ulrich Mayring" <ul...@denic.de>
To: <co...@xml.apache.org>
Sent: Tuesday, April 09, 2002 3:34 AM
Subject: Re: continuation fear (was Re: [status & RT] design challenges)


> Mikhail Fedotov wrote:
> >
> > You won't believe, but I'm also working on issue tracking
> > system and we've choosen Struts over Cocoon recently. The
> > reason was that "it is unproven fact that xml/xslt in
> > general and cocoon in particular improves productivity".
>
> I think XML/XSLT generally is a no-brainer, by now every programmer
> should understand the advantages of that approach and where it might be
> useful. I used to be the only guy here to do XML stuff, but in the
> meantime all my colleagues have learned it and think it's extremely
> productive. No-one wants to go back to proprietary data formats and
> protocols.
>
> Whether Cocoon is the right choice depends on your needs. If you just
> need to do some simple XSLT/XSLFO stuff, then you're probably better off
> using Xalan directly. If you need some simple web apps, you can still
> use Cocoon1 very productively, it's straightforward to learn, pretty
> bug-free and gives you a great start into "XML world" in general.
>
> When you're at that point, you're up for a strategic decision. You know
> enough about XML & Company to make an educated decision about the future
> of your web publishing and web app development needs. There are plenty
> of commercial options out there to consider in addition to switching to
> Cocoon2 (Tamino, Excelon, several CMSes). I would not recommend diving
> head first into one of these professional solutions without some prior
> exposure to the "XML way of doing things". You simply won't have
> identified your needs and thus might end up with an unsuitable product.
>
> Of course, if you have some time and a bunch of not-so-critical and
> not-so-complex things to do, then you can start with Cocoon2 right away,
> it won't cost you an arm and a leg. But note that the Cocoon2 processing
> model is very different from the usual approaches, so it might be
> advisable to start with a more "traditional" system. Cocoon2 asks you
> for a serious commitment and its benefits will pay off only in the long
> run, so I am not surprised that developers without prior XML exposure
> are reluctant to bet their future on it. But I think they should not say
> that it is an unproven fact that XML technology in general is unproven.
>
> cheers,
>
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
> ---------------------------------------------------------------------
> 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

Re: continuation fear (was Re: [status & RT] design challenges)

[Ulrich Mayring <ul...@denic.de>]

Mikhail Fedotov wrote:
> 
> You won't believe, but I'm also working on issue tracking
> system and we've choosen Struts over Cocoon recently. The
> reason was that "it is unproven fact that xml/xslt in
> general and cocoon in particular improves productivity".

I think XML/XSLT generally is a no-brainer, by now every programmer
should understand the advantages of that approach and where it might be
useful. I used to be the only guy here to do XML stuff, but in the
meantime all my colleagues have learned it and think it's extremely
productive. No-one wants to go back to proprietary data formats and
protocols.

Whether Cocoon is the right choice depends on your needs. If you just
need to do some simple XSLT/XSLFO stuff, then you're probably better off
using Xalan directly. If you need some simple web apps, you can still
use Cocoon1 very productively, it's straightforward to learn, pretty
bug-free and gives you a great start into "XML world" in general.

When you're at that point, you're up for a strategic decision. You know
enough about XML & Company to make an educated decision about the future
of your web publishing and web app development needs. There are plenty
of commercial options out there to consider in addition to switching to
Cocoon2 (Tamino, Excelon, several CMSes). I would not recommend diving
head first into one of these professional solutions without some prior
exposure to the "XML way of doing things". You simply won't have
identified your needs and thus might end up with an unsuitable product.

Of course, if you have some time and a bunch of not-so-critical and
not-so-complex things to do, then you can start with Cocoon2 right away,
it won't cost you an arm and a leg. But note that the Cocoon2 processing
model is very different from the usual approaches, so it might be
advisable to start with a more "traditional" system. Cocoon2 asks you
for a serious commitment and its benefits will pay off only in the long
run, so I am not surprised that developers without prior XML exposure
are reluctant to bet their future on it. But I think they should not say
that it is an unproven fact that XML technology in general is unproven.

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

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

Re: continuation fear (was Re: [status & RT] design challenges)

[Mikhail Fedotov <mi...@kittown.com>]

Hi!

> 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.

You won't believe, but I'm also working on issue tracking
system and we've choosen Struts over Cocoon recently. The
reason was that "it is unproven fact that xml/xslt in
general and cocoon in particular improves productivity". 

I.e. it turned out to be not visible at all for our
programmers. I know Cocoon from my own experience, but for
others Cocoon's usefulness is unproven and not visible.

Mikhail

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