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/)
