cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [C2] Sitemap issues to solve
Date Fri, 16 Jun 2000 23:08:51 GMT
Ross Burton wrote:
> > 1) Component Model
> > ------------------
> > The sitemap has the notion of a general component. I think might be
> > dangerous since it could allow cascaded sitemaps to "tweak" the
> > component installation and provide security holes. Since I don't think
> > sitemaps should deal with such high level components, I suggest we
> > remove the
> >
> >  <component>
> >
> > element from the sitemap and only leave
> >
> >  <generator>
> >  <filter>
> >  <serializer>
> >  <matcher>
> >
> > as possible sitemap components.
> So we have names like cocoon.xconf for the <component> tags, and
> sitemap.xmap for the actual sitemap. 

Hmmm, not exactly.

cocoon.xconf --> configurations for the whole Cocoon system
sitemap.xmap --> 

(I like the .xmap extention, very cool, better than .xml that doesn't
mean anything)

> Will cocoon.xconf specify a default
> sitemap, or will the be the responsibilty of the class creating Cocoon?

I'd say:

 connector -> cocoon.xconf -> sitemap.xmap (root) -> sitemap.xmap
(mounted) ---> ... (and so on)
> > 2) Matching architecture
> > ------------------------
> > is an IDREF to the "choosing" component (XXX: should we call it
> > "chooser" instead of "matcher"? should we keep the XSLT model? should we
> > use "matching"?)
> A Chooser seems childish - I'd say a Matcher interface and a <matching> tag.

<choose> keeps the XSLT markup...
> > 3) Parameter percolation
> > ------------------------
> > In the current WD we are able to perform things like
> >
> >   <process uri="/\([0-9]\{4\}\)/\([0-9]\{2\}\)/">
> >     <set-parameter name="year" value="$1"/>
> >     <generator name="serverpages" src="/$1/dailynews.xsp"/>
> >     <filter type="xslt" src:local="./stylesheet/news.xsl"/>
> >     <serializer type="html"/>
> >   </process>
> Strange example - why would there be a different news XSP for each year? 

Why not? each year they change database technology. Stupid, I know, but
who said that business practices are driven by technical intelligence? 

To paraphrase a great scientist we all admire: "we must be flexible
enough, but not more flexible" :-)

> I
> envisage this being used to pass named parameters from the URI to a central
> XSP (or filter/generator etc).

Right, the problem here is what we _don't_ envisage. :)
> [snip]
> > and test if the return object is null to grasp its boolean value. So, if
> > the result is null, the test was not true, if so, the Map contains the
> > parameters that can percolate thru the pipeline and accessed with
> > "$name" inside the sitemap.
> $name will be difficult to express in the sitemap - what is the variable in
> "$foobar"?  You might say the resulting string is the contents of variable
> "foo" followed by the literal "bar", but what if I meant the contents of
> "foob" followed by "ar"?  In "traditional" regexp back-references like $n
> are restricted to $0 to $9, where $0 is the entire pattern.

Good point.

What about ${variable}? or $(variable)? or $[variable]? when the
variable has more than one char, otherwise $x?
> [snip]
> >  <choose type="browser">
> >   <when test="version()">
> >    <filter type="xslt" src:local="./style/mozilla-$version/news.xsl"/>
> >    <serializer type="html"/>
> >   </when>
> >  </choose>
> Another parsing problem - what is the name of the variable referenced here?
> We know it's "version", but how does Cocoon?

Right, see above.
> I'm going to ponder this one over the weekend and post some more comments.
> Something else I've been wandering about: how does Cocoon 2 know what the
> root of the sitemap is?  IMHO, the <sitemap> tag should have a root="..."
> attribute.  At the moment it's relative to the sitemap file itself, right?
> What is the sitemap is not loaded as a file, but instead passed to Cocoon as
> a Document object or a SAX stream?

No, Cocoon will load the sitemap thru a loader and a loader is always
responsible to correctly understand path relativity.

> Also, when Cocoon 2 is embedded the
> current path has to be set correctly, or else no files will be found.
> Forgive me if I'm totally wrong here - I haven't investigated this in the
> current codebase for Cocoon 2, so I may be totally wrong.

No, you are right. The location of the sitemap file identifies the
relative resources, which are relative to the loader used to load the

For example, if the sitemap is on the "xml-cocoon" CVS module in path
"/xdocs/cocoon-docs.xmap", then "index.xml" identifies the file that is
located in the same path in the same module on the same server. Then,
suppose we have another sitemap inside "/lib/fop.jar" in the same CVS
module in the path "/xdocs/fop-docs.xmap"... and so forth.

The idea of the "local" loader implements relativity of resources not
only on path location but also on loader choice. So, depending on the
nesting level, "local" changes behavior, so you might access reference a
file inside a jar included into a CVS module. Or an document fragment
relative to another document fragment which follows the sitemap schema 
all contained into an XML based content management system.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message