cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Use of flowscript or the pyramid of contracts
Date Fri, 23 Apr 2004 09:31:55 GMT
Guido Casper wrote:

> Stefano Mazzocchi wrote:
> 
>>>> 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.
> 
> 
> I don't think developers aren't eager to write reusable components. But 
> currently it's just that hard to come up with components really making 
> the user's life easier.
> 
> The problem I have with cocoon.getComponent() is the user's side of the 
> fence. getComponent() doesn't say anything about the granularity of a 
> component as Avalon allows for (and encourages) components of any 
> granularity. Avalon has been there before flow and is intended to make 
> the Java developer's life easier not the flow user's.
> 
> The services for flow users should be coarse grained and high level. And 
> I believe that the user shouldn't have to deal with technical details 
> like component lifecycle (and having to call releaseComponent()).
> 
> Please note that I don't want to discuss the pro/vs. release(). I really 
> don't care wether the developer has to call release (at least right now 
> :-).
> 
> I for sure don't want to increase overall complexity. But if I could 
> trade reduced user complexity for increased developer complexity I would 
> do.
> 
>>
>>>> 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.
> 
> 
> Exactly. I'm just thinking about a better way than an Avalon component 
> (and thought it might be the right time to speak up now that we are 
> designing a new container).
> 
>>
>> 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.
> 
> 
> Yes, I realized that flowscript is the perfect solution to the missing 
> piece of the pyramid of contracts for the webapp space.
> 
> I just feel we should much more leverage it for this role and it is 
> vital to give more emphasis to the user.

I'm wide open to proposals that help in this direction, Guido, because 
I'm 100% with you on this and if we are ruining the pyramid of contract 
with flowscript I want to know and I want to fix this as fast and 
painless as possible.

I continue to believe that cocoon.getComponent(role) within the real 
block framework is good enough for what we need.

But if you have a better idea, well, you know I'm always ready to throw 
stuff away when I see something better.

-- 
Stefano.


Mime
View raw message