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:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
