You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Derek Hohls <dh...@csir.co.za> on 2005/05/11 15:39:13 UTC
Spring "web flow" vs Cocoon Flow/Continuations
Anyone seen the article:
http://www.theserverside.com/articles/article.tss?l=SpringWebFlow
and can comment on how these two approaches might be
compatible (or in conflict?)
PS for an interesting choice for a demo of "saving state" - see:
http://www.jroller.com/page/kdonald/20050417#my_wife_is_hot_and
BTW, why is that other web application frameworks such as Struts
Tapestry, WebWorks etc are *always* mentioned in these types of
articles and Cocoon just never makes an appearance??
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Spring "web flow" vs Cocoon Flow/Continuations
Posted by Sylvain Wallez <sy...@apache.org>.
thomas wrote:
>
>
> --On Freitag, 13. Mai 2005 12:07 Uhr +0200 Sylvain Wallez
> <sy...@apache.org> wrote:
>
>> 3 years ago, the cocoon devs were discussing "flow maps", and
>> addition to
>> the sitemap to define page flow using an XML grammar. We always ended up
>> with verbose XML languages having control structures (the infamous
>> "if"),
>> and then some people came with continuations, at first is Scheme (a Lisp
>> dialect - eck!) and then Javascript, and later pure Java.
>>
>> Having a real programming language allow to *very easily* write complex
>> page flows, as you can use all the language's features for control
>> structures, and simply use regular variables to store the interaction
>> state. Amazingly easy and powerful.
>>
>> The main advandage I see to a declarative approach is that it allows to
>> build visual tools (i.e. graphical editors) to design the flow. But the
>> underlying XML files are very likely to be a real mess in realworld
>> complex use cases.
>>
>> Note however that Cocoon's flow engine is pluggable and that we have 3
>> versions of it today:
>> - flowscript, using Javascript to define the flow (business logic should
>> be kept in Java)
>> - javaflow, a pure java implementation
>> - apples, an experimental implementation (used in Daisy IIRC) which may
>> be actually closer to Spring's approach.
>
>
> as i understood it the results of a flowscript-operation don't
> generate sax-events. so you can use flowscript only at the end of a
> pipeline. is that true?
Yes, a flowscript doesn't generate sax events, and no, it doesn't come
at the end of a pipeline. Rather the contrary, as the flow is the
controller in the MVC (model - view - controller) pattern.
Actually, Cocoon is sometimes called "MVC+" as it has two levels of
controlers:
- a level is the sitemap, a controller that maps requests to some
processing (be it a flow call or a pipeline)
- another is the flow, which manages the interaction of the user with
the business logic across successive pages.
So the flow takes some decisions according to the application state, and
then calls a pipeline using an internal request (i.e. using the
"cocoon:" protocol).
> and is it equally true for all 3 flow-implementations mentioned above?
Yes, they all behave similarily: do some stuff and call a pipeline. They
differ either in the programming language used or in the way interaction
state is saved across requests.
> in that case i would think that some logic within the sitemap (the
> infamous "if") wouldn't be so bad (for very comlex problems one could
> still decide to leave the sax-stream and use flows). but i might very
> well overlook something obvious or essential.
Actually, there are some ifs already in the sitemap: <map:match>,
<map:act> and <map:select> are control structure, and are similar to an
"if" or a "switch". But the purpose of these control structure is to
allow some simple conditional building of pipelines, and complex
conditions should be computed at the controller level, i.e. in the flow.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Spring "web flow" vs Cocoon Flow/Continuations
Posted by Reinhard Poetz <re...@apache.org>.
thomas wrote:
> --On Freitag, 13. Mai 2005 12:07 Uhr +0200 Sylvain Wallez
> <sy...@apache.org> wrote:
>
>> 3 years ago, the cocoon devs were discussing "flow maps", and addition to
>> the sitemap to define page flow using an XML grammar. We always ended up
>> with verbose XML languages having control structures (the infamous "if"),
>> and then some people came with continuations, at first is Scheme (a Lisp
>> dialect - eck!) and then Javascript, and later pure Java.
>>
>> Having a real programming language allow to *very easily* write complex
>> page flows, as you can use all the language's features for control
>> structures, and simply use regular variables to store the interaction
>> state. Amazingly easy and powerful.
>>
>> The main advandage I see to a declarative approach is that it allows to
>> build visual tools (i.e. graphical editors) to design the flow. But the
>> underlying XML files are very likely to be a real mess in realworld
>> complex use cases.
>>
>> Note however that Cocoon's flow engine is pluggable and that we have 3
>> versions of it today:
>> - flowscript, using Javascript to define the flow (business logic should
>> be kept in Java)
>> - javaflow, a pure java implementation
>> - apples, an experimental implementation (used in Daisy IIRC) which may
>> be actually closer to Spring's approach.
>
>
> as i understood it the results of a flowscript-operation don't generate
> sax-events.
a flowscript (or any other alternative) invokes a pipeline
> so you can use flowscript only at the end of a pipeline.
the sitemap connects a request with a flowscript call. The flowscript invokes a
pipeline that produces SAX events.
is
> that true? and is it equally true for all 3 flow-implementations
> mentioned above?
that what I said is equal for all 3 alterntaives
in that case i would think that some logic within the
> sitemap (the infamous "if") wouldn't be so bad (for very comlex problems
> one could still decide to leave the sax-stream and use flows).
can't follow you here. what's your usecase?
> but i
> might very well overlook something obvious or essential.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Spring "web flow" vs Cocoon Flow/Continuations
Posted by thomas <th...@stray.net>.
--On Freitag, 13. Mai 2005 12:07 Uhr +0200 Sylvain Wallez
<sy...@apache.org> wrote:
> 3 years ago, the cocoon devs were discussing "flow maps", and addition to
> the sitemap to define page flow using an XML grammar. We always ended up
> with verbose XML languages having control structures (the infamous "if"),
> and then some people came with continuations, at first is Scheme (a Lisp
> dialect - eck!) and then Javascript, and later pure Java.
>
> Having a real programming language allow to *very easily* write complex
> page flows, as you can use all the language's features for control
> structures, and simply use regular variables to store the interaction
> state. Amazingly easy and powerful.
>
> The main advandage I see to a declarative approach is that it allows to
> build visual tools (i.e. graphical editors) to design the flow. But the
> underlying XML files are very likely to be a real mess in realworld
> complex use cases.
>
> Note however that Cocoon's flow engine is pluggable and that we have 3
> versions of it today:
> - flowscript, using Javascript to define the flow (business logic should
> be kept in Java)
> - javaflow, a pure java implementation
> - apples, an experimental implementation (used in Daisy IIRC) which may
> be actually closer to Spring's approach.
as i understood it the results of a flowscript-operation don't generate
sax-events. so you can use flowscript only at the end of a pipeline. is
that true? and is it equally true for all 3 flow-implementations mentioned
above? in that case i would think that some logic within the sitemap (the
infamous "if") wouldn't be so bad (for very comlex problems one could still
decide to leave the sax-stream and use flows). but i might very well
overlook something obvious or essential.
thanks for your time,
thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Spring "web flow" vs Cocoon Flow/Continuations
Posted by Sylvain Wallez <sy...@apache.org>.
Derek Hohls wrote:
>Anyone seen the article:
>http://www.theserverside.com/articles/article.tss?l=SpringWebFlow
>
>and can comment on how these two approaches might be
>compatible (or in conflict?)
>
>
These approaches are similar in that both save the interaction state,
send its ID to the browser, that sends this ID back to the server to
restore the interaction state.
The implementation of the interaction state and the definition of the
flow are however really different:
- Flowscript and Javaflow use continuations that hide most of the state
management problem, allowing to write the interaction in a regular
programming language.
- Spring uses a declarative approach to define the different states,
actions and transitions.
Now which one is better?
3 years ago, the cocoon devs were discussing "flow maps", and addition
to the sitemap to define page flow using an XML grammar. We always ended
up with verbose XML languages having control structures (the infamous
"if"), and then some people came with continuations, at first is Scheme
(a Lisp dialect - eck!) and then Javascript, and later pure Java.
Having a real programming language allow to *very easily* write complex
page flows, as you can use all the language's features for control
structures, and simply use regular variables to store the interaction
state. Amazingly easy and powerful.
The main advandage I see to a declarative approach is that it allows to
build visual tools (i.e. graphical editors) to design the flow. But the
underlying XML files are very likely to be a real mess in realworld
complex use cases.
Note however that Cocoon's flow engine is pluggable and that we have 3
versions of it today:
- flowscript, using Javascript to define the flow (business logic should
be kept in Java)
- javaflow, a pure java implementation
- apples, an experimental implementation (used in Daisy IIRC) which may
be actually closer to Spring's approach.
>PS for an interesting choice for a demo of "saving state" - see:
>http://www.jroller.com/page/kdonald/20050417#my_wife_is_hot_and
>
>
Dead easy with flowscript too...
>BTW, why is that other web application frameworks such as Struts
>Tapestry, WebWorks etc are *always* mentioned in these types of
>articles and Cocoon just never makes an appearance?
>
>
Because, as Sebastien outlines, we're bad at communicating, and should
definitely improve in this area.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Spring "web flow" vs Cocoon Flow/Continuations
Posted by Sebastien Arbogast <se...@gmail.com>.
> BTW, why is that other web application frameworks such as Struts
> Tapestry, WebWorks etc are *always* mentioned in these types of
> articles and Cocoon just never makes an appearance??
I don't know of all of them but I think the first reason is that those
frameworks use mainly common technologies like JSP, JSTL and so on. So
they capitalize on common knowledge, which makes them more mature and
"easier" to use. Maybe...
Besides, those frameworks seem to be really centered on presentation
layer, but Cocoon is more than that so it's not always obvious to plug
with other components and define the fronteer as clearly as in
Hibernate/Spring/Struts. Even if CHS is an excellent example of a
perfect integration with a very clear frontier between the three
tiers.
But you're right, it should be mentioned. Maybe it's a problem of
communication. Maybe Cocoon could spread the word with more...
pedagogy. If that's what it wants :-P
--
Sebastien ARBOGAST
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org