Guido Casper <[EMAIL PROTECTED]> writes:
As I alway try to keep my flowscript as "exception-handling-free" as possible and as I feel that this sentiment is not shared by everyone, I thought it is a good oportunity to come up with another concern.
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).
I think there is something else going on here also: as technologies
mature there is a push to make them more accessible. Making them more
accessible means adding in capabilities that don't require formal CS
training. JavaScript and scripting languages in general are a good
example of this. They enable a whole new level of accessibility for a
whole new audience that wants to "just do it" and have never heard of
best practices.
This is good, the demand for such a level of capability means a product
has reached a level of appeal where even non CS users are wanting to use
it. As such, we shouldn't be surprised if some of the uses for these
capabilities don't employ what a more traditional Cocoon developer would
consider best practices.
So, my high level advice would be not to try and control such
experimentation too much. Watch and see what comes of it and then start
to develop a new level of best practices. Cforms is an example of this;
the community in general is still working to figure out what is best
practices for cforms: how to bind, how to add action handlers, etc.
There's a general picture emerging, but it's not clear (as an outside
observer) exactly what parts of cforms embody Cocoon flow best practices
yet. I think this will become much clearer over time.
So, I think, yes, you can have both strategy and best practices but it's just going to take time for the best practices to emerge and having a strategy on how to guide that will help (if we really understand what the strategy will do).
The pattern to apply might be to seperate the things changing from the things staying the same. Recognizing what stays the same and what might change requires exerience as well. But the Cocoon community should have some experience in that space as what should stay the same IMO is the desire to separate the concerns and to keep the pyramid of contracts.
----
Welcome to my first RT :-)
Gee, I have RT all the time, I just never write them down ;-)...
Well, OK ... I do have ... hmm ... point taken :-)
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.
I think the line has always been blurred (does a user modify the
sitemap?),
Well, yes. It's the _user_ building the application.
The line may not be always crystal clear. But the point is that it allows you to separate concerns. And even if it's always myself wearing a developer hat or wearing a user hat it surely makes complex applications more manageable and gives me a development model quite appealing to big project teams.
What I currently complain about is that the user role has been degenerated to a stylesheet writer but it should be the one reponsible for the application as a whole.
it's just that flow makes it even more obvious that there is an overlap. The capabilities implemented for flow add capabilities for general scripting (in addition to flow control) that is going to be used; there's a pent up demand for easier development that Flowscript provides.
A nice scripting engine may provide a boost for developer productivity (which is great). But general scripting is not and will never be what makes Cocoon ubiquetous. What I am trying to find out is which concerns are really affected by the way we use scripting currently and may use it in the future.
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.
Hmm, yes, maybe, I'm not sure... I think you're always going to have to
expect a bit of a lag between new capabilities and best practices.
Encoding a limited set of available interfaces means that we already
know what the best practices are. For some areas that's probably true
(parts of the guts of Cocoon), for other areas like DB access, I think
we're still learning. Some areas are going to be very blurry for some
time, flow control itself has a lot of different meanings to a lot of
different people.
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".
Like I said, flow means a lot of things to a lot of people. Not sure you can have a single definition; I try to distinguish between application flow and screen flow.
Exactly, let's try to find out which concern are currently affected by flow and if and how these concerns may be better separated. I'm not saying we should immediately do that but start thinking about it.
Limiting Cocoon flow to screen flow may bring some of the clarity you want, but telling people they can't do application flow would remove a lot of RAD capabilities from Cocoon that are also useful even for people who know how to do things the "right" way (eg; from what I understand Linotype was developed using flow as a RAD tool?)
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 perhaps the main reason is that more time is needed for them to
emerge?
Yes that might be one reason. Another one IMO is that it's much easier to (conceptually) come up with a reusable sitemap component (being a specialized thing) than it is to come up with a reusable flow component.
Guido
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 implicitly 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 you could slowly move towards enforcing a FOM only access to Cocoon; maybe start with two levels of access: a default FOM only and a "RAD flag" (developer_mode='true') that be configured to say to Cocoon that a developer wants to allow script X to have access outside of the FOM model ?
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 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 -------------------------------------------------
