cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Casper <>
Subject Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Mon, 19 Apr 2004 18:35:43 GMT
Hunsberger, Peter wrote:
> Guido Casper <> 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 
>>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 
>>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.


>>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 
>>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. 
>>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 
>>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 

Guido Casper
S&N AG, Competence Center Open Source
                     Tel.: +49-5251-1581-87
Klingenderstr. 5
D-33100 Paderborn

View raw message