cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Escaping Sitemap Hell
Date Fri, 07 Jan 2005 19:28:06 GMT
Nicola Ken Barozzi wrote:
> Stefano Mazzocchi wrote:
> 
>> Daniel Fagerstrom wrote:
> 
> ...
> 
>>> A real map for the site should be tree structured like the linkmap in 
>>> forrest. Take a look at the example in [1], (I don't suggest using 
>>> the "free form" XML, something stricter is required). Such a tree 
>>> model will also help in planning the URI space as it gives a good 
>>> overview of it.
>>
>>
>> Forrest and cocoon serve different purposes.
>>
>> While I totally welcome the fact that Forrest has such "linkmaps", I 
>> don't think they are general-enough concepts to drive the entire 
>> framework. They are fine as specific cases, especially appealing for a 
>> website generation facility like forrest, but as a general concept is 
>> too weak.
> 
> 
> While I agree with your reply, I think that I understand what problem 
> Daniel thinks he sees.
> 
>  A sitemap is not the _map_ of a _site_.
> 
> That's why we made site.xml.
> 
> But saying that this should drive processing is IMHO not correct. In 
> fact, it's the opposite. We made the site.xml stuff in a different file 
> so that it would *not* interfere with processing.

Right. I see that.

> 
> ...
> 
>>> Choosing Production Pipeline
>>> ----------------------------
> 
> ...
> 
>>> Now instead of having the rule:
>>>
>>> *.x.y.z ==> XYZPipeline
>>>
>>> we have
>>>
>>> * where repository:{1} have properites {x, y, z} ==> XYZPipeline
>>>
>>> or
>>>
>>> * where repository:{1}.x.y.z exists ==> XYZPipeline
>>
>>
>>
>> Oh, a rule system for sitemap!
>>
>> hmmmm, interesting... know what? the above smells a *lot* like you are 
>> querying RDF. hmmmm...
> 
> 
> At Forrest, we have done a similar thing, and are still in the process 
> of finishing it. IT states something like this:
> 
>  "Forrest processing should not be tied to URLs."
> 
> IOW, Forrest should not process a file differently just because it's in 
> a particular directory, but using other characteristics, like mime-type, 
> DTD, schema, etc. For us, an URL is a partitioning decision of the 
> content creator, not of the application creator.
> 
> Many sites fail to do this, and URL matching has become the easiest way 
> of partitioning Cocoon's processing, although not the best.
> 
> You can make your own matcher... and here is where we should 
> concentrate, by defining new blueprints that don't use the URL as a 
> matching system.
> 
> Forrest is doing it for docs... someone else can do it for apps :-)

See? the problem is that you are partitioning the matching space with 
URL matchers... I strongly feel that most of the problems that Daniel 
(and you) are outlining will just go away if you used non-URL matchers.

-- 
Stefano.


Mime
View raw message