cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Less is More, Finite State Machines and Balkanization
Date Mon, 14 Jul 2003 20:00:02 GMT
Christopher Oliver wrote:

> Sylvain Wallez wrote:
> <snip>
>> Now, part of my job is giving Cocoon presentations and trainings, so 
>> I also talk about flowscript, continuation trees, the end of 
>> back-button infamy, etc. I always have a low of wow's and people find 
>> this very interesting.
>> And then, there are two categories of people :
>> - those who have no existing background on page flow problems. They 
>> have no problems with our way of doing it.
>> - those who have some background, either as code or as trained people.
>> People in the second category, after the mind blow is finished, ask me :
>> - "why use JavaScript ? I'm used to plain Java and don't want 
>> JavaScript". 
> Well, let's work on a Brakes/Java based flow engine that supports 
> continuations. We can also use the Eclipse Java compiler to behave as 
> a Java interpreter (see 
> so that you get all the development-time benefits of a scripting 
> language and still use Java and get code-completion in your IDE.  This 
> seems to me like a much better solution for such people, than 
> reverting to a FSM approach simply because they don't want to use 
> JavaScript. 

I never said that I wanted to revert to FSM because people don't want to 
use JavaScript. What I said is that the current interfaces underlying 
the flow are too much oriented towards an _interpreter_ supporting 

Now your proposal is exactly what I'm aiming at. But it ain't 
JavaScript, and as such has no place in Cocoon's CVS if we consider the 
community results that have been recalled clearly. Or are you ready to 
trash your Rhino-with-continuations in favor of having Rhino-generated 
classes augmented by Brakes ?

>> - "I have an existing backend" or "I use Struts". "How can I link it 
>> to the flow ?"
>> What should I say ? Use actions ? Use Struts as the toplevel servlet 
>> and Cocoon for the view (I did this once) ? 
> Well, I would say that it is very easy to convert a Struts app to use 
> Flowscript. I originally converted the IBatis  Petstore 
> (, a Struts application, to the current Cocoon 
> Petstore sample (with Velocity as the only view) in 1 day. 

Sorry, Chris, you don't get the point : I also would be able to do that. 
But the problem is different : there are people out there (yes, 
customers) that *don't want* to do that. And this all where the whole 
problem lies.

> Is "StrutsFlowEngine" really a viable approach?

It's not viable as something promoted by Cocoon. I never said the 
contrary. But it's more than viable to convince people to move to Cocoon 
without breaking all their existing code and knowledge. The latest 
Jakarta News says that Struts has the biggest user mailing-list with 
more than 2700 subscribers. What about attracting some of them to Cocoon ?

> If so, why not put the code in the scratchpad to demonstrate it. 

As you know that there is no such code, I don't know how I should 
consider this. As I'm an optimistic guy, I'll take it positively, as the 
scratchpad it the place for future mutations of the code base. So thanks 
for the offer.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message