cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <>
Subject Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Date Thu, 31 Jul 2003 12:23:56 GMT
On 31/07/2003 13:35 Stefano Mazzocchi wrote:

> On Wednesday, Jul 30, 2003, at 18:48 Europe/Rome, Nicola Ken Barozzi  
> wrote:
>> ?permalink=workflow_viewlets.html
> did you guys ever programmed java with JavaStudio? it was a nice little  
> app that sun released in the early java days. it was visual programming  
> of java code thru LabView style drag-drop-link of javabeans.

Yep. Sugar candy appealing to lusers like myself. :-)

> It was sooooooo cool when you saw a demo.
> Horrible to work with it.
> why? visual programming is bullshit.
> It take half an hour to write a visual representation of something like
>  if (blah) {
>    dothis();
>  } else {
>    dothat();
>  }

Still, I found the demos pretty valuable with the process variables 
being explicitely being created in a separate pane. Makes one think more 
about what he is doing.

The nice thing of such a GUI is that it enforces people to make use of 
the exposed API, and makes hacks around it, reaching for areas where 
scripting authors shouldn't come, a bit more difficult.

                                 - 0 -

I just had a discussion in the car with Bruno about where Apples is 
heading (basically he bringing me uptodate - thank you Bruno), and my 
layman's conclusion is that different schools of development style are 
emerging when building webapps with Cocoon.

1) glueing together ready-made available components using XSPs and the 
bag of available Actions
2) Actions and custom Avalon-Cocoon components, which tend to overload 
the sitemap with programmatic constructions in the long run
3) 'Webcontinuations flow with Javascript', where people depend on the 
availability of Javascript wrappers for common libraries (JDBC, OR 
frameworks, ...) - with the challenge of coming up with decent JS 
libraries to make sure one doesn't have to reach at too many Java stuff 
using 'Packages' - the really cool thing is of course the instant 
gratification of save/reload/test
4) 'Apples' which shifts the encapsulation of business and service 
components back to full-blown Java, with a simple Apple class calling 
upon them while exposing flow decisions in a very lighweight manner in 
order to call the correct pipelines
5) 'Dywel' which seems to be going after Struts practices with a nice 
dash of Avalonization to go with that

3) and 4) being heavily dependent on the JXTransformer approach (which 
is a Good Thing IMHO)

How we are going to manage and support these five schools of thought, I 
honestly don't know (not even if we need to be worried altogether), but 
I envision some some white-bearded guy is already chuckling in his 
corner (

<interlude advise="don't take this too seriously">

More stupidity being put forward, I would humbly suggest to explicitely 
name the methodologies:

1) 'Barbara', in kind remembrance of B. Post
2) 'Carsten, the Early Years'
3) 'SchemoVidiuChrismatron'
4) 'Species' - since Apples and Pears are way to generic already, and 
it's what Darwin was all about
5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly 

... in order to be able to ask a Cocoonie: what religion are you in? 
"Oh, I used to be an early CultofBarbara groupie, but now I tend to 
worship the mighty SchemoVidiuChrismatron."


Kidding aside, is my categorization more or less correct? Might be cool 
to put on a slide once.

Steven Noels                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  
stevenn at                stevenn at

View raw message