cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Sat, 17 Apr 2004 21:38:00 GMT
Guido Casper wrote:

> Welcome to my first RT :-)


> From the arrival of flow I liked it very much. But at the same time I 
> felt it weakens the pyramid of contracts to a great extent (as Gianugo 
> recently pointed out as well).
> The pyramid of contracts defined several roles, but what made it so 
> powerful (IMO) was the strong contract between a user and a developer of 
> Cocoon. I feel like the distinction between these two not being that 
> clear anymore.

This is very valuable criticism.

> It may be not immediately clear what this distinction is and I thought a 
> lot about it (and my opinion on this may be debatable). So here it goes:
> "A user is someone building applications without writing a single line 
> of Java code."

Ok, let's use this notion for this context.

> Some people might argue: Hm, if you try to build your application 
> without writing any Java code you end up in a mess. But the point of the 
> above is, if that user needs a component written/extended in Java he can 
> go to "his" developer and tell him: Go off and build this component for 
> me and come back when you're done. When this developer comes back with 
> the ready-built component the user goes on finishing his app. This is a 
> strong contract. An important detail that easily slips through is the 
> fact that it is the user being responsible for the application's 
> architecture not the developer.

Yes, this is crucial in the pyramid of contract: Administration tells 
Logic what to do.

> So one might come up with the most simple definition of a Cocoon user as 
> "someone building Cocoon apps without having eclipse installed" (Idea 
> and JBuilder counts as well - but Emacs doesn't :-).
> With flow this distinction is not that clear anymore.

Well, I could say that "cocoon is web glue, and a cocoon user is the one 
that glues the pieces together".

Then, I can say that resources are defined in one place and flow logic 
is defined in another.

> The original intention of flow was to be a facility to describe page 
> flow logic, since the sitemap was not suitable for this. This clearly 
> belongs to the realm of the user building applications (although now 
> having to code something). 

Yes, absolutely.

> The reasoning was that describing your page 
> flow with a piece of (scripting) code is many times clearer than coming 
> up with some obscure FSM-based XML vocabulary. The code would be so 
> simple that any user (having seen some piece of code before) should 
> grasp it immediately.


> Over time the intention of flow became "glueing your components 
> together". Developers tend to (ab)use flow for "its own benefits" and 
> use it the same way they use Java (Javascript is not all that different 
> from Java). I feel that the goal to build reusable (high level) 
> components went out of focus because of that (it may be harder to build 
> reusable components for the flow layer then it was/is for the sitemap 
> and it may even be harder to hold on to the pyramid of contracts while 
> moving from the publishing to the webapp space).

I 100% agree that this is a problem but it's not flow to blame is the 
fact that java is so much harder to write and avalon components so much 
harder to install!

Let's not throw away the baby with the dirty water here: flow is crucial 
for the success of our "user" because there is no way that she can be 
able to control complex webapp flow in the sitemap without resorting to 
strange things like actions.

It is true that flow is so easy to use that programmers abuse it. I've 
been there myself and I did have to force myself to write components in 
java instead of writing them in flow directly.

But I *did* feel the need for more component orientation, it's just that 
having to restart the system everytime was just too painful!!

With the compiler classloader, things became much easier!!!

I don't blame flow to be simple, I blame java to be less usable! We have 
to fix that to compensate and our problems will be drasticly reduced 
because people don't like to write business logic in scripting languages!

> I'm not saying this necessarily is something bad. It just puts a 
> different perspective on the development process. Today with advancement 
> of IDEs and automated build processes these roles and processes may have 
> changed a bit and the user being "responsible" for all the flow layer 
> does not work anyway, does it? Your code repository is the collective 
> entry point into the system (being closely controlled via a set of 
> automated tests) and Cocoon users and developers are working more 
> closely "integrated" (if they are still to be distinguished roles at all).
> Did the pyramid of contracts silently vanished? I don't think so. Just 
> lift the user to an "educated user" (if he hasn't always been). However 
> this doesn't mean to tell the user: go and figure how to use all the 
> public classes available from the flow layer. It rather means use flow 
> like it's intended to be used and just use a well-defined limited set of 
> available interfaces.
> At first I thought, don't bother writing this email, everyone thinks the 
> same. But I suspect there may be radically different opinions about that.
> Yes, we habe FOM. The difference to the sitemap is that the sitemap 
> enforces the contract while flow doesn't.

One drastic approach would be to stop flow from being able to access 
java at all, if not thru FOM. I would be in favor of that once we have 
the real block system running, but at that point it might well be too late.

> Why do "flow people" constantly fall back using Java classes? 

In my case, I tried to avoid it as the plague.
Do they
> put to much into the flow layer? The expectations for the flow layer 
> seem to be so various. I fear that this fact does more harm than good to 
> Cocoon. Hm, I don't even have a definition of "flow layer". Why is there 
> no library of flow components readily available? I don't know but I 
> suspect it's harder to build reusable flow components than it is to 
> build reusable sitemap components (the level of component reusability of 
> the sitemap is unparalleled). At the same time it is too easy to just 
> get my stuff finished with flow. Which is exactly what makes flow 
> currently so powerful and what may count in many cases. However this 
> particular advantage may be just temporary.
> I guess I just want to hear what other people would think about that. 
> Even if this Email leads to nothing but people looking from another 
> perspective, I'm happy :-)
> I don't even have a real proposal. But I'm thinking about restricting 
> flow to FOM and "flow-intended" components (or their "flow-intended" 
> interface like with CForms). Another part may be some guidelines on how 
> to create (which should be simple of course :-) and use such components. 
> Just exposing Avalon or whatever components to flow doesn't seem to be a 
> big (the right) step forward (and part of this "wrong" step seems to be 
> cocoon.getComponent/releaseComponent) as this implicitely tells the 
> user: yes, flowscript and Java components share the same API. Completely 
> disabling the use of arbitrary Java classes from flowscript doesn't seem 
> doable either (it _is_ a useful thing for the developer) or even 
> desirable. What may be a good idea IMO (and please tell me if I'm 
> talking bullshit) is to let "flow-intended" components implement a 
> Scriptable interface (which should always be high level and easy to be 
> used by users) and provide some kind of doclet mechanism that generates 
> the docs for our "official" flowscript API.
> The reason I'm thinking about this is that I wondered wether the 
> repository block justifies its existence now that we are short before 
> JSR170 comes along. And in my opinion it does. JSR170 is a Java API 
> while I want my _users_ building a CMS. Does it make sense and is it 
> achievable?
> Guido


View raw message