cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: [RT] Managing Flow and Resources
Date Sun, 09 Dec 2001 21:30:59 GMT
On Sun, 9 Dec 2001 17:06:44 +0100 (CET), Torsten Curdt <> wrote:

> On Sun, 9 Dec 2001, Steven Noels wrote:
> > > -----Original Message-----
> > > From: []
> > > Sent: zondag 9 december 2001 1:07
> > > To: Berin Loritsch
> > > Cc:; Michael Hartle
> > > Subject: Re: [RT] Managing Flow and Resources
> >
> > > Regarding the XML syntax of the sitemap, I actually believe it's a lot
> > > easier if we just have the sitemap written in Scheme, instead of
> > > XML. We can add new stuff much more easily than trying to invent a
> > > syntax in XML. Here's how a sample sitemap would look like in the
> > > Scheme syntax:
> > >
> > > (sitemap
> > >   (define-pipeline docbook-html (dir filename)
> > >     (generate (concat dir filename))
> > >     (xslt "docbook-html.xsl"))
> > >
> > >   (match "/myapp/*/*.xml"
> > >     (pipeline docbook-html))
> > >
> > >   (match "/app2/*/*.pdf"
> > >     (pipeline
> > >       (generate (concat dir filename))
> > >       (xslt "docbook-html.xsl")))
> > > )
> > >
> > > "sitemap" above is just a Scheme function that reads its arguments and
> > > generates another function to match a request against the specified
> > > patterns. Another side-effect of executing "sitemap" is that all the
> > > "pipeline" functions will setup in the Java space the transformers
> > > objects according to the description. The serialization process could
> > > be added automatically by the "match" functions, if no serializer has
> > > been defined. Similarly one can think of lots of possible semantics
> > > associated with the above description.
> >
> > uh oh...
> >
> > One of the great features of the current Cocoon2 distribution *is* the
> > XML-syntax of the sitemap, even at its DTD/Schema-less state. Although I like
> > the usage of Rules-based engines to drive dynamic execution paths, I do not
> > see why we need YAS (Yet Another Syntax) to configure Cocoon.
> +10
> Let's stay with the XML syntax! Otherwise would be a step backwards!
> Maybe we can work out a different way to combine the current sitemap
> with the new flow managing.

OK, we'll stay with the XML syntax for the sitemap.

> I'd also like to see the flowmap to have XML syntax. I'm still dreaming
> of developing some visual tools for editing this stuff. This would
> be WAY easier when everything is XML based!!

The flowmap is actually nothing more than a program that drives the
navigation between pages. Because of that a programming language is
much more natural to express the logic, than XML.

> Ovidiu, could you give a more complete example how these implicit
> flow definition could look like for a more complex multipage form?!
> (I'm still sceptic about this approach - still like the turing machine)

Here's a simple example adapted from one of the papers I pointed
to. I'm using a syntax more familiar, not actual Scheme.

In this example you have three pages. The first page prints some text
and asks for the first number. The second page prints out the first
number obtained from the first page, and asks for the second
number. The third page displays the two numbers and the result.

The text for each page is written in three different XML files. Each
file is processed through a pipeline that takes the XML doc and
generates the output. The send-response() function is responsible for
doing this processing. It takes the page to process, the pipeline name
that processes the page, and an optional data structure that contains
data which could be used to generate the pages.

The send-response function is special. After it sends the response to
the client, it suspends the execution of the thread serving the
request. Before doing this, it stores the continuation of the
procedure in an internal hash table. This hash table contains as keys
URLs, and as values continuation objects. When a particular URL is
invoked, the Scheme engine obtains from the hash table the
continuation object and executes it. The net effect is that the
suspended function continues the execution right were it was.

To be able to correctly specify in the generated HTML pages what is
URL to invoke next, send-response() makes available to the pipeline
the continuation URL. During the processing of the file, various
transformers can make use of this URL to embed it in the generated
result page.

To be able to incorporate URLs to older points in the processing, the
send-response() function could return as value an object that contains
the URL to its continuation. You can pass this URL in the optional
dictionary, as an additional argument, if you wish so.

function addNumbers(HttpRequest request)
  send-response("first-page.xml", "my-pipeline");
  first = request.getIntParameter("first");
  send-response("second-page.xml", "my-pipeline", {"first" = first});
  second = request.getIntParameter("second");
  result = first + second;
  send-response("third-page.xml", "my-pipeline", {"result" = result});

In this example each send-response has its own URL. The default URL
which selects the addNumbers() function is specified in the
sitemap. The newly generated URLs for each send-response() function
have unique URLs, which possibly are derived from the initial URL
(still need to decide on the format).

If the user uses the back button in the browser, he/she will select a
page that has URL pointers to old continuations. When the "submit"
button is pressed, the user effectively selects an old continuation
object, at a point in the program that was executed in the past.

You can control for how long the continuations are kept around, aka
for how long you allow the user to go back in the processing, by
simply modifying the continuation object. We can specify a default
timeout for all the continuation objects which are created, and have a
function that modifies this default.

Here's an example of how one can change the expiration time of a

  set-default-expiration (60m); // Set expiration time to 60 minutes
  continuation = send-response("some-page.xml", "some-pipeline");
  continuation.setExpire(0); // Expire it now!

The above example was a very simple, and doesn't justify why one would
use continuations instead of describing the flow in a FSM, or even
spreading the logic across multiple pages.

However the language you implement the page flow into is complete: it
has loops, conditionals etc. You can implement as complex of a logic
you want, depending either on the values of parameters present in the
request, or on values obtained from your low-level logic. The language
also allows you to call arbitrary Java objects, which implement the
logic of your application.

I hope this example makes you understand why this approach is much
easier to implement Web applications. I'm sure many of the things I've
described above may change over time, as we implement things, expose
it to users, and get more feedback on useful things to have. So don't
take things too literaly, I've just tried to give you a taste of the

Best regards,
Ovidiu Predescu <> (inside HP's firewall only) (my SourceForge page) (GNU, Emacs, other stuff)

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

View raw message