Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <4082BF8E.5050608@s-und-n.de>
Date: Sun, 18 Apr 2004 19:49:02 +0200
From: Guido Casper <gcasper@s-und-n.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Use of flowscript or the pyramid of contracts  (was Re:
 [RT] Checked exceptions considered harmful)
References: <408103CA.105@s-und-n.de> <4081A3B8.1060303@apache.org>
 <4081A615.7060805@apache.org>
In-Reply-To: <4081A615.7060805@apache.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

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.

Guido

-- 
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
                     Tel.: +49-5251-1581-87
Klingenderstr. 5    mailto:gcasper@s-und-n.de
D-33100 Paderborn   http://www.s-und-n.de
-------------------------------------------------