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). > ---- > > Welcome to my first RT :-) Gee, I have RT all the time, I just never write them down ;-)... > 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?), 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. > 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. 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? > 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? >
