forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject Re: Implementing direct html-support
Date Tue, 02 May 2006 13:29:10 GMT

Thorsten Scherler wrote:

>> Unfortunately this is not working properly (with the linkrewriter-part
>> throwing an error in some pages) while it does work when I insert the
>> same block into the system sitemap.xmap right above the orginal matcher.

> Makes somehow sense since placing it *before* the original match will
> work. First matched - first served. 

Not sure what you mean by that. This is not a problem of priorities,
project site maps should and do override the system site map.

>> Two questions:
>>         - Is this because the required components need to be required
>>           components are declares in the sytem sitemap and need to be
>>           referenced differently here?

> Do not understand the question. What components? You are using standard
> components (already declared in forrest) or did I miss something?

linkrewriter uses cocoon components that are declared in the
system-sitemap (nothing special used) but I was wondering if they are
available just like that in the project sitemap.

>>           If so, how do I reference this properly (I also need this to
>>           implement php-support) which I want to do in the project
>>           sitemap in any case.
>>         - Should I insert my matcher into heads sitemap.xmp like I
>>           did thus implementing a preferred processing of html?

> IMO that should rather go into an input plugin on its own rather then
> core. Not only that it is heavily skin specific but can have ugly side
> effects for the rest of forrest (since it e.g. reserves an url space
> **body-*.html and further is doing a html-to-html conversion of the body
> (as I understand it) and not xdocs).

I don't unserstand why. Since it is preparing for the transition to
xhtml as core formal, why would it become a plugin?

> In the dispatcher we are now using extensions like **.body.xml which are
> conform to our naming conventions.

Hmmm, does that mean I should aim for a different matcher then?

Ferdinand Soethe

View raw message