cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Casper <>
Subject [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Sat, 17 Apr 2004 10:15:38 GMT
As I alway try to keep my flowscript as "exception-handling-free" as 
possible and as I feel that this sentiment is not shared by everyone, I 
thought it is a good oportunity to come up with another concern.

Hope it's OK to steal this thread.

Antonio Gallardo wrote:
> Hi Ugo:
> I understand that "time" is a good teacher. Things that now are
> easy,some years ago was not. Building the first path is the worse
> task. And since programming is a very dynamic beast, where what
> yesterday was the "best and recommended by the gurus", today "the same
> gurus tell you that this is totally wrong".

Yes, not only the gurus' opinions changed but "things" changed.

I keep on wondering wether it just takes time to build best practices or 
best practices are really constantly changing.

If I could choose between constantly adjusting best practices or seeking 
for a long term strategy I would (obviously) opt for the latter. I'm not 
sure what would be best for Cocoon though (probably doing both).


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.

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

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.

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.

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

Why do "flow people" constantly fall back using Java classes? 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 


Guido Casper
S&N AG, Competence Center Open Source
                     Tel.: +49-5251-1581-87
Klingenderstr. 5
D-33100 Paderborn

View raw message