cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Burton <>
Subject Re: [C2] Link filtering and Content aggregation
Date Mon, 02 Oct 2000 19:19:34 GMT
> If you only used stylebook, I know you love it and don't see any
> problems with it: it's a magic tool that does the job for you (more or
> less an autodoc)... but if you ever tried to write a skin for it...
> well, you know what I mean when I say there are problems.

Do _not_ remind me of the time I wrote a new skin for Stylebook!

> link filtering
> --------------
> IMO, we need to expand the sitemap semantics to allow resources to be
> blocked from CLI crawling. The best way, IMO, is to add a specific
> attribute to the resource indicating elements... these elements are
>  - match
>  - mount
> and we just have to define an attribute name between
>  - crawl
>  - crawlable
>  - walk
>  - walkable
>  - ???
> for example
>  <map:match patter="someuri" crawl="no">
>   ..
>  </map:match>
> will return a specific error number to the CLI requesting the page.
> What do you think?

The sitemap needs this sort of flexibility, there could be a section of
the URI space which could potentially return gigabytes of files (for an
example, see  I'm +1 on... crawl="yes|no".

> Content Aggregation
> -------------------

> It was already proposed to use the "cocoon:" protocol and to access them

And I'm a big +20 on this.

> so 
>  <sitebar xinclude:href="cocoon:/sitebar"/>
> is expanded at runtime as
>  <sitebar>
>   <item xlink:href=".."/>
>   <item xlink:href="index"/>
>   <item xlink:href="user-guide"/>
>  </sitebar>

I take it that in this example the resource /sitebar returns the XML:

    <item xlink:href=".."/>

And _replaces_ the original <sitebar> element.  The same behaviour would
be the same if the original element was, for example: <foo
xinclude:href="cocoon:/sitebar"/>, right? I'd feel safer using just
<xinclude:include href="cocoon://sitebar"/>, as I think the syntax is

Oh, IIRC the URI RFC states that the format is protocol://host/path, so
the resource should be cocoon://sitebar or cocoon:///sitebar depending
on the sitemap.

This requires a custom URL handler, doesn't it?  How is this going to be
handled?  org.apache.cocoon.utils.URL?

Ross Burton

View raw message