cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Burton" <ross.bur...@mail.com>
Subject Re: [C2] Sitemap issues to solve
Date Fri, 16 Jun 2000 20:05:11 GMT
> 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.  Will cocoon.xconf specify a default
sitemap, or will the be the responsibilty of the class creating Cocoon?


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

> 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?  I
envisage this being used to pass named parameters from the URI to a central
XSP (or filter/generator etc).

[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.

[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?


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?  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.

Off to relax at last...
Ross


Mime
View raw message