cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: SoC between flow and sitemap
Date Sun, 18 May 2003 21:53:07 GMT
Stefano Mazzocchi wrote:

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

Mine also ;-)

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

5) you refactor some of the hacky JS into some nice reusable Java classes

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

I experienced this.

>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

I experienced this also (see [1]). But the demo wasn't done to a hacker 
: it was done to a potential customer who was totally blown away. 
Imagine the situation : other competitors on this project were proposing 
some non mainaintable hardcoded solutions 4 times more costly (no, I'm 
not joking). The demo took a few days to setup (because of some 
client-side hacks to write), and we showed the customer in a 1 hour 
phone meeting how he could himself managage some small changes in his 
data model.

Cocoon, with flow script and a good form handling package (which IMO 
XMLForm is not) totally rocks the planet, and even the universe.

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

Again, similar experience, even if the ratio isn't that high. The flow 
gives you more time to be creative on the client-side, and allows faster 
adaptation of the server-side to new client-side features.

So you end up with very simple-yet-powerful server-side code, and some 
fancy client-side features. What can we ask more ?

>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


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

The TreeProcessor was written at a time where we were talking of 
flowmaps, and we were thinking of writing it using an XML language. The 
TreeProcessor is a framework for the defining the implementation of 
Processor (the main Cocoon interface) in XML, using an evaluation-tree 
based approach.

The Ovidiu hacked those strange Scheme things in the scratchpad and 
Chistopher added continuations to Rhino. And sitemap is very likely to 
stay the only language implemented using the TreeProcessor ;-)

So the important word in TreeProcessor is "Processor", which is the 
interface this component implements.

The same applies to the flow : in the view pipeline, we care about data 
given by the flow controller, but don't care wether it's written in JS, 
Scheme, continuation-enabled Java or stackless Python.

So I don't see the problem of using the word "flow" in the object model, 
as it is in no way related to the actual implementation of the flow.

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

And I see a reason to *not* force the link internally ! I agree that 
Cocoon should provide a single "official" implementation of its main 
parts : Sitemap for pipeline and JS for the flow. But at the same time, 
not hardcoding the implementation allows for further experimentation in 
this area without having to break core parts of Cocoon. And this may in 
the future allow to change the official implementation if something 
better comes up (Mmh... like continuations in Java, and hence in 
Rhino-generated bytecode?).


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

You cannot store the continuation ID in a cookie, as the cookie has a 
single value for the entire browser session, both in time and space 
(separate windows). The continuation ID *really must* be transmitted by 
the request (either form values or part of the URI).

This is only one of the reasons why fetching the continuation ID cannot 
be hardcoded. Another example is the XMLForm integration with the flow 
(yep, one more nice thing by Christopher!), where a single page holds 2 
continuations ID : the current one associated to "next", and a previous 
one associated to "prev".

So we really need to be able to extract continuation IDs in various ways 
from the request. And the sitemap is IMO the best place to do that.

Now we could adapt the continuation naming schemes. Currently, we have a 
single global naming space with long numbers to ensure uniqueness and 
avoid "continuation hijacking". We could have a simpler naming scheme 
for those continuations where the global variable scope is tied to the 
session (using Cocoon.createSession). This could even be a simple 
integer sequence, with an initial prefix to differentiate them from 
global continuations. This would also solve potential problems of the 
ContinuationsManager on clustered servers.

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

Ah, so you will understand my point above.


>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! ;-)

Actually, I guess Carsten recently wrote his first flow script. I invite 
everyone to make this experience : write a small webapp with the flow. 
Once you will have started to grasp the concepts of continuations, you 
will find that all this state management we've done for years using 
sessions really sucks ! Once you tried flow script, there's no turning 
back !



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message