cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <>
Subject Re: [RT] A Groovy Kind of Sitemap
Date Thu, 29 Jul 2004 01:19:58 GMT
Stefano Mazzocchi wrote:

> if we had a unified sitemap+flowscript -> sitescript that used 
> components *and* continuations as "native objects" of the language, 
> would the need for separation be that high and the notion of merging 
> the two so sinful?
> I don't know.
> But I would *love* to have such a "sitescript" and play with it so see 
> how it feels... because, if you think about it, there is no way to 
> reuse a sitemap without touching flowscript, they are 
> interconnected... are we experiencing "overseparation of concerns" 
> forced by the non-scriptable syntax of the sitemap?

Isn't this what httpd.conf is?  If scripting is allowed, how far behind 
is something like mod_rewrite, setting global variables in one section 
to be read in another, etc.?  I'm not talking about code in Cocoon core 
in SVN.  I mean once it hits the real world and people start actually 
using it.

Basically, if someone on a Cocoon team doesn't get XML, they're 
basically useless.  On the bright side, getting someone up to speed and 
giving them documentation on XML is trivial.  The hardest part about the 
sitemap is just getting folks around the concepts of URI 
matcher->generator->transformer->serializer->back to client and URI 
matcher->flow function->processing->back to sitemap pipeline.  This 
"hardest part" is not going to become substantially easier with any 
alternate syntax.

Explaining the XML syntax to someone has proven for me to be relatively 
trivial.  If the person doesn't get XML, they're not touching Cocoon in 
the first place.  Note: someone may not know XSLT but still grasp XML.  
Many of those same people I've been teaching Cocoon do not know how to 
program in Java (although they're learning).  They do have a background 
in JavaScript though as it's hard to avoid learning it in web page 

I like to think of the sitemap as an engine for "this is where the 
request goes in and here's where it comes out."  Once you hit a Flow 
function, you've hit the first black box.  (Just like components in Flow 
should remain a black box.)  All you know is that it enters a logic 
segment and will "come out" in some pipeline you've specified.  The fact 
that you are not intimately tied to what this logic does is IMHO a good 
thing.  I do acknowledge that it would be nice to have easy access to 
the complete picture and easily enforce all of the possible outputs, but 
once you hit real logic (in any full programming language), your ability 
to lock things down diminishes.  Currently, since the sitemap determines 
all outputs available to the sendPage* calls, I think this may be about 
as good as it's going to get.  (Open to be proven wrong!)

I'm rambling now, I know.  But before I finish, I just want to remind 
that XML is a given.  It permeates everything in Cocoon.  XML 
(well...structured content) is the pipeline.  If the back-end 
implementation for caching, generators, transformers, serializers, etc. 
were ported to .Net and C#, XML would still be a given.  If it were 
ported to C as an Apache module, XML would still be a given.  One of the 
things I have always admired about Cocoon was this fact.  Of course 
porting to something besides Java would be a major PITA -- especially 
for those of us with a few custom Java components, but I'd rather see 
the underlying model -- the public interface, the steering wheel, 
whatever you want to call it -- remain as XML.  Let Flowscript be 
implemented in Java, JavaScript, Python, Groovy, Scheme, and whatever 
else a development team is used to (eventually...not necessarily right 
now), but leave the front door as XML.

Not because it is the most concise syntax in number of characters 
typed.  Not because it can cover all future possibilities.  Because it 
works.  Because it's familiar.  Because someone with the least skills 
necessary to use Cocoon, needs only know XML.  Cocoon == XML.  If it's 
not equal to XML, then why aren't we all jumping ship to Apache 2.0 filters?

My $0.02 for what they're worth.  I could be wrong.  I've been wrong 
before on many occasions...

- Miles Elam

View raw message