cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Klaasen" <>
Subject RE: [C2]Action proposal (long)
Date Thu, 09 Nov 2000 11:04:37 GMT
> -----Original Message-----
> From: Sylvain Wallez []
> Sent: donderdag 9 november 2000 11:58
> Giacomo Pati a écrit :
> > 
> > Hi all
> > 
> > I'd like to thank you all for patiently waiting for this proposal.
> > I know I was very ternse the last days. This is because I'm have
> > to finish some projects apart from Cocoon.
> > 
> > Action proposal
> > 
> </snip>
> A few thoughts that came to mind when reading the proposal.
> As far as pipeline description is concerned, the sitemap is great : a
> pipeline is simple sequence of transformations and the associated
> language is compact.
> Actions (which I think are *really* needed to build web apps with
> Cocoon) are more complex since they tackle the logic of the 
> application,
> which can have a complicated structure. Action-chains are a kind of
> reusable block (or a method ?), but I think very soon new needs will
> emerge when people will use actions : if-then constructs, iterations,
> etc.
> So why not allow a kind of <map:logic> tag in some sections of the
> sitemap to allow people to express complex behaviours 
> directly in Java ?
> Simple things should be simple (use the limited sitemap language wich
> covers 80% of your needs), complex things should be possible (do it in
> Java). Moreover, which not allow map logicsheets which would allow to
> factorize high-level constructs such as web site structure or 
> behaviour
> (actions) using custom tags ?
> What do you think of it ?

My gutt feeling with Giacomo's proposition was that there would be too much
"programming logic" (as opposed to "administration logic") in the sitemap.
And you seem to feel the other way around.

I really think the sitemap shouldn't allow too much programming, because in
the end, you would end up programming everything in the sitemap. As stated
in Stefano's slides: "A publishing framework should impose strict yet
flexible practices". Let's not forget the "strict" (which in the end is
necessary to allow the "flexible", imho)


View raw message