Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Sun, 9 Dec 2001 17:06:44 +0100 (CET)
From: Torsten Curdt <tcurdt@dff.st>
To: <cocoon-dev@xml.apache.org>
Subject: RE: [RT] Managing Flow and Resources 
In-Reply-To: <OKEDLKGMIPDOCJHOEDEFGELFCHAA.stevenn@outerthought.org>
Message-ID: <Pine.LNX.4.31.0112091622090.23075-100000@mogh.dff.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 9 Dec 2001, Steven Noels wrote:

> > -----Original Message-----
> > From: ovidiu@cup.hp.com [mailto:ovidiu@cup.hp.com]
> > Sent: zondag 9 december 2001 1:07
> > To: Berin Loritsch
> > Cc: cocoon-dev@xml.apache.org; 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.

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!!

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)
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org