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:48:05 GMT
Guido Casper wrote:

>> Why do "flow people" constantly fall back using Java classes? 
> In my case, I tried to avoid it as the plague.

Sorry, hit the wrong key and sent the email ;-) Let me continue.

> 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 think that if we come up with with reusable FOM components, we have 

on the other hand, I think there are reusable FOM "aspects" that might 
be reusable, but let's not go there now.

sitemap is declarative glue while flow is procedural glue.

if there is too much spaghetti code in between them, there is something 
wrong and we have to fix that.

I believe that inputmodules/outputmodules do already pose a significant 
complexity to the clean separation. I think input modules *are*not* 
necessary once you have a clearly defined way for flow to pass 
parameters to the sitemap.

I do understand this is radical and i'm open for constructive criticism, 
but please come up with examples to show me why you really need 

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

I think that cocoon.getComponent(role) would be enough if writing those 
components would be as painless as writing flowscript. No need for more 
complex stuff.

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

the JSR 170 is a complex beast. I would wrap it with a Repository avalon 
component, make the interface really simple and pass this to the 
scripting layer, hiding all the complexity inside.

That's how I would do it.

And yes, I still believe in the pyramid of contracts, even more than in 
the past, but the sitemap is not enough, we need something else, we 
can't write script in XML.


View raw message