cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: SoC between flow and sitemap
Date Sun, 18 May 2003 16:33:09 GMT

oh, what a happy way to wake up :-)

on 5/18/03 5:44 AM Carsten Ziegeler wrote:

> Stefano Mazzocchi wrote:
>>>I hope to be fueling some discusion that might lead to clarifying 
>>>some of the contracts usefull for general web-app-development 
>>>inside cocoon (even for those not using flow maybe).. it could be 
>>>that I just overlooked some ready excisting facts of life, please 
>>>point those out then
>>>[1] flow communicates with pipeline components behind the scenes.
>>>(Actually it's not the only component doing so, but that should 
>>>not be seen as a justification)
>>>sendpageandwait() sets two important objects as attributes to the 
>>>request attribute... (the continuation and the so called 
>>>bean-dict (hashmap-like 2nd argument to the function)
>>>these get picked up by jxpathtransformer (or generator) or any 
>>>other pipeline-component that wants to use that information.
>>>And there is my fundamental itch with this approach: those 
>>>pipeline-components are to be written to deal (exclusively) with 
>>>the quite arbitrarily manner in which these 'beans' or usefull 
>>>objects are communicated between the deciding logic (flowscipt) 
>>>and the consuming publication pipe components
>>Yes, this 'weak contract' is a known problem. The way the flow
>>communicates with sitemap components is underfined.
>>In the past, Carsten expressed the need to avoid adding flow-specific
>>hooks into the cocoon object model. Carsten, do you still feel that way
>>about it?
>>I know you dislike flowscript and would like to be able to deploy your
>>stuff without it, but this is forcing such an important internal module
>>to be based on such a weak contract and many (myself included) dislike
>>this very much.
>>Besides, if you don't use flowscript tags into your sitemap, the classes
>>are not even loaded by the treeprocessor, so you can deploy your
>>machinery without even shipping rhino and things would work anyway.
>>I would suggest we add a Flow object to the object model.
> Putting it simple: I changed my mind - I think flow is very, very 
> useful and should belong to the core. 


this made my day.

> Now, I didn't had time to catch
> up on the flow stuff and the object model etc. and I was thinking
> in the last days how to integrate flow much better into the
> pipeline execution, so basically to address the problem from above.

Ricardo and I completed the FOM discussion on the whiteboard last night.
RT on flow object model coming up next. Stay tuned.

> Now, I always liked continuations but I didn't like javascript and
> the scripting approach. But I changed my mind on the second one,
> although you have to take care about what you do in javascript.

of course. and I can tell you right now that it will be abused... but at
least, it provides an easy migration path between today's weakly-SoC web
 environments and a strong-SoC environment as cocoon.

I tell you what my experience with it is so far:

 1) you write your flow the hacky way (basically you make it work, this
normally includes cut/paste based programming and results in duplication
of code everywhere)

 2) after the thing works, you start modifying it and you figure out
that you have to modify the same code in several places

 3) therefore, you come up with more general methods that refactor the
concept and remove the cut/paste (but the application still runs). You
do this one step at a time, checking that the application still runs
(very similar to test-driven programming)

 4) you come up with a working app, a clean flow and your users/client
feedback was incorporated early on, in all modification cycle (which
normally lasts a few hours, not more)

Voila', best of both worlds! RAD + solidity + elegance + darwinistic
development (aka XP).

I believe that the development productivity of Cocoon 2.1 will be
*orders* of magnitude faster than any other web technologies.

When I showed Linotype to Ricardo he was very impressed. When I showed
him that the entire flow was 120 lines of code. He was litterarely blown

Think about it: linotype is currently reaching a thousand lines of
javascript code on the client side and a hundred on the server side.
It's correct! the amount of logic in the client-side editing is ten
times more complex than the one on the server side!!

see it: cocoon introduces a *sane* metric to measure the amount of
complexity of a web site. This has been the holy grail in all accademic
fields for years. It's *so* cool when a real project does more than all
the accademic resources in the world combined! it tells you something
about the power of true open and darwinistic development.

> So, flow the number one feature for building web applications
> and in combination with the cocoon pipelining you have a platform
> that beats everything else on earth (at least for me).


>>I think it would be much more separate to provide a
>>Flow object in the object model and let the components take care of it.
>>components that interoperate with the flow known about it anyway so that
>>can load the right object and play with it with no need to
>>flow->object_model translation dictated by the sitemap.
> Yes.

I agree with Marc that we might want to name that object in such a way
that is not directly connected to the flow, just like TreeProcessor is
not SitemapProcessor.

I would be against pluggable implementation of the state transition
controlling logic (of which, admittedly, the flow is just one possible
implementation), as much as I'm against pluggable implementations of the
sitemap semantics (which is one of the possible description of our
states). But I don't see a reason to force link internally.

>>>So, It's not because the js-script and sitemap.xmap are different 
>>>files that they shouldn't be under control of the same person... 
>>>(which it nowadays needs to be as I tried to argument)
>>I've been working alone on my last two flowscript based cocoon webapps
>>and I can tell you that I *enjoyed* having separate files where
>> - one declaratively indicates the the pipelines
>> - the other indicates the transition between them and feeds data to
>>them based on some external business logic.
>>The first parameter of sendPage* is *NOT* a URL, a real locator, but a
>>*URI* a name of the pipeline you wish to be called. Why? because the URL
>>of the browser is *NOT* influenced by the URI that you indicate in that
>>call (unlike in client-side redirects!)
>>I really see no reasons to change this behavior.
> To be honest, the first time I saw flow I didn't like the separation
> either. I always thought that I want to use flow directly in the sitemap.
> But now I agree with Stefano (and all the others), that separating these
> things is much better.

I'm *very* glad to hear that.

> What I currently don't like that much (but it's ok for now), is that
> you have to define the hooks for the flow in the sitemap. So you have
> to match the incomming request and call the flow from the sitemap.
> And then you call the pipeline from the flow. I'm thinking about
> directly invoking the flow (if a contination is available perhaps)
> and not querying the sitemap first.

I agree with you that this is something we might want to further
research later on. But I believe we don't have enough real-life
experience on the flow to judge what is the best way of doing
transparent mapping.

For example, in the first Ovidiu examples, the continuation was passed as


This appeared rather harmless, but it turned out to be *very* weak in
real life because you always had to use absolute URIs since the
continuation URL was in another location and you didn't always know how
to relativize (../../-like) the URLs from the current state to the
continuation and back.

Chris (very brilliantly, as he always does, spoiling us! ;-) changed the
above into


which is not a resource in a different absolute location, but a resource
*alongside* of the current location. That is: relative. Removing the
need for any URL relativization.

it seems like an innocent and trivial change: it's *NOT*! in fact, it
improved framework reusability immensively!

But I currently dislike having big long numbers in my URI and I'm
currently thinking about storing the continuation ID in a cookie (just
like session IDs are normally passed) and have a cookie matcher in my
sitemap instead of a URI matcher.

So, I started disliking the call-with-continuation part of the sitemap,
but now I very grateful I can play with it myself and find out the best
continuation-passing style of my URI space.

One day we might find a one-size-fits-all solution for this and might
want to make it implicitly available (as sessions are done for the
servlet API). This, admittedly, will improve early-on usability, but
making things transparent will reduce the ability of the people to
*know* what's going on and plan their resources better (which is the
problem with the servlet APi where very few understand what sessions
really are and how they are implemented)

So, while I understand your concerns, I think we just need more
first-hand experience before attacking this problem and, for now, it
works and it's flexible enough for trying out different
continuation-passing styles without forcing core changes.

> So, a big +1 for flow :)

Hurray! ;-)


View raw message