cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@apache.org>
Subject Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Sat, 17 Apr 2004 11:11:26 GMT
Guido Casper wrote:

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

And don't forget the role of XML in the contract: while the user waits 
for her component to be finished, she can go on and use an XML mockup, 
changing the implementation only at a later stage.

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

Well, I think there is room for improvement here, leaving FOM interfaces 
intact. We have been strongly advocating IoC and passive API, but if we 
do a reality check, we can see that the way we're using component 
managers today doesn't quite make a difference between our supposedly 
passive/inverted API and those arbitrary JNDI lookup from J2EE world: if 
we keep passing the same component manager around, filled with the same 
set of components, we are doing nothing different so:

> 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 tend to like this idea. Or, in a slight variation, a way to expose to 
flow just a reasonable subset of components via a restricted component 
manager. I don't think there is a need for a specific interface to be 
implemented at the component level: a mechanism for the site 
administrator to label specific components as available to the flow 
layer (or the opposite: mark some specific components as not available) 
could be enough.

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

It's difficult to say without having JSR170 available. On pure paper, it 
makes sense to have a set of glue components, but just as long as 
contracts are solid.

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Blogging at: http://www.rabellino.it/blog/)

Mime
View raw message