Hope it's OK to steal this thread.
Antonio Gallardo wrote:
Hi Ugo:
I understand that "time" is a good teacher. Things that now are easy,some years ago was not. Building the first path is the worse task. And since programming is a very dynamic beast, where what yesterday was the "best and recommended by the gurus", today "the same gurus tell you that this is totally wrong".
Yes, not only the gurus' opinions changed but "things" changed.
I keep on wondering wether it just takes time to build best practices or best practices are really constantly changing.
If I could choose between constantly adjusting best practices or seeking for a long term strategy I would (obviously) opt for the latter. I'm not sure what would be best for Cocoon though (probably doing both).
----
Welcome to my first RT :-)
From the arrival of flow I liked it very much. But at the same time I felt it weakens the pyramid of contracts to a great extent (as Gianugo recently pointed out as well).
The pyramid of contracts defined several roles, but what made it so powerful (IMO) was the strong contract between a user and a developer of Cocoon. I feel like the distinction between these two not being that clear anymore.
It may be not immediately clear what this distinction is and I thought a lot about it (and my opinion on this may be debatable). So here it goes:
"A user is someone building applications without writing a single line of Java code."
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. An important detail that easily slips through is the fact that it is the user being responsible for the application's architecture not the developer.
So one might come up with the most simple definition of a Cocoon user as "someone building Cocoon apps without having eclipse installed" (Idea and JBuilder counts as well - but Emacs doesn't :-).
With flow this distinction is not that clear anymore.
The original intention of flow was to be a facility to describe page flow logic, since the sitemap was not suitable for this. This clearly belongs to the realm of the user building applications (although now having to code something). The reasoning was that describing your page flow with a piece of (scripting) code is many times clearer than coming up with some obscure FSM-based XML vocabulary. The code would be so simple that any user (having seen some piece of code before) should grasp it immediately.
Over time the intention of flow became "glueing your components together". Developers tend to (ab)use flow for "its own benefits" and use it the same way they use Java (Javascript is not all that different from Java). I feel that the goal to build reusable (high level) components went out of focus because of that (it may be harder to build reusable components for the flow layer then it was/is for the sitemap and it may even be harder to hold on to the pyramid of contracts while moving from the publishing to the webapp space).
----
I'm not saying this necessarily is something bad. It just puts a different perspective on the development process. Today with advancement of IDEs and automated build processes these roles and processes may have changed a bit and the user being "responsible" for all the flow layer does not work anyway, does it? Your code repository is the collective entry point into the system (being closely controlled via a set of automated tests) and Cocoon users and developers are working more closely "integrated" (if they are still to be distinguished roles at all).
Did the pyramid of contracts silently vanished? I don't think so. Just lift the user to an "educated user" (if he hasn't always been). However this doesn't mean to tell the user: go and figure how to use all the public classes available from the flow layer. It rather means use flow like it's intended to be used and just use a well-defined limited set of available interfaces.
At first I thought, don't bother writing this email, everyone thinks the same. But I suspect there may be radically different opinions about that.
Yes, we habe FOM. The difference to the sitemap is that the sitemap enforces the contract while flow doesn't.
Why do "flow people" constantly fall back using Java classes? 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 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.
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?
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
-------------------------------------------------
