cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Status of 'Apples'?
Date Thu, 15 Jan 2004 09:55:04 GMT

Stephan Coboos wrote:
> Hello,
> I had read about the apples block and I would like to use it in some 
> parts of my application. There is just one big question: I'd read that 
> apples is in alpha status, so will it be (really) supported in future 
> and when is the release planned? In 2.2?
> Thank you.

Safe bet here and now is to choose FlowScript.

There is no release plan for apples whatsoever.  Since the code just 
works and no more commits have been hitting it since some months (not 
counting  syncing with other changes or bugfixes) you can safely just 
use it.  However I don't have the feeling there have been enough 
group-discussions and user feedback to talk about a stable API, here. 
(hence the alpha label)
I know it's a chicken and egg problem, but it will require actual users 
and deeper discussions to actually get it somewhere.

So Where?
IMHO Apples' future (if any) should be closely related to the pursuit of 
some best practices pattern in the separation between Java and 
JavaScript code when using FlowScript.  This opposed to it being 
perceived sometimes as an alternative or even competition to FlowScript...

There have been some recent hints on people needing better guidance in 
this role-disctinction between both Java and FlowScript. I think a lot 
of practical reasons for using the _current_ Apples will vanish when 
that is there.

I'm hoping that time is getting there: as more people are using 
FlowScript I think were getting closer to the point where there is 
enough critical mass of sample-code in which the patterns can be 

If those patterns can be meaningfully solidified in an API (which I 
really believe), then that API should be 'Apples' IMHO.  Still having 
the possibility to call an 'Apple' (i.e. single-step controller-logic) 
directly from the sitemap (without flowscript) would then be considered 
an optimizing feature (and not the todays' perceived fundamtal clash of 
visions, which it IMHO never was).

In the end, it would in fact finally make up for the seemingless 
usage-limit-transitions that were originally envisioned here:
(possibly avoiding the recurring flow vs. actions theme as well?)

And although everyone is invited to speak up, only 'time' will really tell.

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message