Why do "flow people" constantly fall back using Java classes?
In my case, I tried to avoid it as the plague.
Sorry, hit the wrong key and sent the email ;-) Let me continue.
Do they put to much into the flow layer?
The expectations for the flow layerseem to be so various. I fear that this fact does more harm than good to Cocoon. Hm, I don't even have a definition of "flow layer". Why is there no library of flow components readily available? I don't know but I suspect it's harder to build reusable flow components than it is to build reusable sitemap components (the level of component reusability of the sitemap is unparalleled). At the same time it is too easy to just get my stuff finished with flow. Which is exactly what makes flow currently so powerful and what may count in many cases. However this particular advantage may be just temporary.
I think that if we come up with with reusable FOM components, we have failed.
on the other hand, I think there are reusable FOM "aspects" that might be reusable, but let's not go there now.
sitemap is declarative glue while flow is procedural glue.
if there is too much spaghetti code in between them, there is something wrong and we have to fix that.
I believe that inputmodules/outputmodules do already pose a significant complexity to the clean separation. I think input modules *are*not* necessary once you have a clearly defined way for flow to pass parameters to the sitemap.
I do understand this is radical and i'm open for constructive criticism, but please come up with examples to show me why you really need inputmodules.
I guess I just want to hear what other people would think about that. Even if this Email leads to nothing but people looking from another perspective, I'm happy :-)
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.
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.
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.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
