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] 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 rpmfind.net).  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:

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

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

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

Mime
View raw message