Guido Casper wrote:
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 layer
seem 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.
You might be right here but don't forget that it is not always web _applications_ why our users take Cocoon. It is very often simple _publishing_. Input modules make it *very* easy for them to e.g. read out a request parameter without having to go the detour of using flowscript.
-- Reinhard
