cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: [RT] A Groovy Kind of Sitemap
Date Wed, 28 Jul 2004 15:07:18 GMT
Marcus Crafter <>
> On Wed, 2004-07-28 at 14:15, Carsten Ziegeler wrote:
> > But let not implementation details (or technics) drive the 
> syntax. It 
> > is more important to have a good sitemap language than to 
> have a clean 
> > and small implementation.
> I agree too mate.
> Something that I'm wondering about is what the relationship 
> would be between flowscript and sitemap-script if we allowed 
> the sitemap to be scriptable.
> My first impression would be that the 2 would merge - the 
> temptation would be there for our users to write their 
> flowscript around their sitemap definition (good thing or bad thing?)
> The XML syntax prevents keeps flow and sitemaps separate - 
> perhaps its worth working out the relationship between both concepts?

I was wondering about this also.  Some may recall that over the years
I've also wanted to implement a XSLT version of flow: an XSLT that spits
out the current page in response to various xPath matches.  Functionally
this merges the sitemap with XSLT yet the two are driven from different
declarations: a page production hierarchy, vs. a flow hierarchy.  (While
we're at it we should probably throw in a work flow hierarchy.)  The
interesting thing here is, you end up with hierarchies of intermeshed
hierarchies.  Now XML and XSLT may not be the perfect language for
managing a graph but at least you can do it (at least for some
restricted cases).

I'm having a hard time seeing how one could do the same generalization
with any non-declarative language?  You'd basically have to end up
allowing each processor (page production, presentation-flow, work-flow)
to call each other but the opportunities for infinite loops and
non-provable interactions would abound?

I'm not saying don't do Groovy or whatever, but the value of XML isn't
just in the direct usage of the tools (ie; using a parser within
Cocoon).  There is a lot of associated work going on around XML that one
may eventually want to exploit in Cocoon.  

As others have said, one needs to step back and look at the overall
objective: what do you want Cocoon to do when you feed it a request
(either via http or CLI or whatever)?  Figure out all the high level use
cases and their interactions, step back, generalize and repeat.
Personally, I end up with something more like RDF and ontology traversal
than I do with scripting...  I don't think many people could afford the
hardware to do that in real-time for large scale web sites, so I come
back to XML technologies as a reasonable compromise for the near term.

View raw message