cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: [status & RT] design challenges
Date Sat, 06 Apr 2002 03:25:07 GMT
On Fri, 05 Apr 2002 22:59:48 +0200, Stefano Mazzocchi <> wrote:

> > Selectors can run after Transformers only if another pipeline is
> > called, and this will basically force you to use the flow pipeline
> > for this, since in fact it's flow we're talking about.
> > 
> > As I see it, Matchers, Selectors and stuff can easily be put all
> > in the flow part, but this makes Cocoon too "procedural".
> > 
> > An easy tip: if you serve web pages, use the pipeline only. If you
> > need to make complex decisions and procedures on the flow, use the
> > flowmap.
> I wouldn't venture to state design patterns *before* the flowmap and
> the sitemap get integrated.
> Ovidiu, how long do you think it would take to have the two live
> together?

They already live together! Maybe I wasn't too clear when I described
this in a message sent on the Friday, two weeks ago, before
JavaOne. But essentially you can start playing with it today, if it
weren't for this ExcaliburComponentManager bug which prevents Schecoon
from working. For testing, I am using a slightly older version of
Cocoon from CVS which works fine.

The current Schecoon integrates Sylvain's interpreted sitemap with the
flow engine. The flow engine is written in such a way that multiple
languages that support continuations can be used. I decided to drop
the previous design which was relying heavily on implementing most of
the stuff in Scheme.

Currently JavaScript is the only language fully supported, but Scheme
is in the works. Depending on the Scheme implementation performance
compared to the JavaScript one, I may decide to go ahead and implement
jWeave, the Java-like language front-end for the Scheme interpreter.

JavaScript support is provided thanks to the work of Christopher
Oliver <>, who was very kind to take his
previous work on saving the Rhino state, and evolving it to support
first class continuations. I have to thank Jason Foster for pointing
out Christopher's work, and indirectly persuading me to rethink my
initial approach.

There is a very basic calculator example available in Schecoon, that
shows how the control flow integrates with the sitemap. Check out the
sitemap and the webapp/examples/calc/calc.js files for more details.

I'd like to work on a more complex example, perhaps a simple shopping
site, but I don't have the bandwidth to do it alone. If somebody else
would like to join as a volunteer, please let me know.

I'm working on writing documentation, which will include a description
of how things are designed to work together, and a best practices
document. There are several issues one needs to be aware of when
writing using the flow control layer, and I want to make sure I
document them.

I've also started working on a functional regression test suite for
Cocoon. This is based on the Anteater framework, and it currently
tests the calculator sample from Schecoon. It should be very easy to
adapt it to the main Cocoon, to test the main Cocoon pages. I'll
create a similar setup for the main Cocoon distribution; I would be
grateful if people will start writing tests for it.

For the future, I'd like to explore how the control flow integrates

- Ivelin's work on form validation.

- exposing business logic as Web services. The control flow layer
doesn't care what is the output generated by a Cocoon pipeline, so
this should be feasible.

- security and scalability issues when using the usage of potentially
large continuation objects maintained by the control flow.

The immediate problem is fixing the bug in ExcaliburComponentManager,
that prevents Schecoon from running. If anyone knows more about this,
please let me know.

Ovidiu Predescu <> (GNU, Emacs, other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message