forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Implementing direct html-support
Date Tue, 02 May 2006 16:06:01 GMT
El mar, 02-05-2006 a las 15:29 +0200, Ferdinand Soethe escribió:
> 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.

No, not always is the project site map overriding the system site map.
That highly depend on the matching/calling one chooses. 

You are right it got mounted first but e.g. matches like cocoon:/ will
match the core sitemap and *not* the project sitemap (which would have
be cocoon://). 

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

Yeah, *should*. ;)

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

First AFAIR our upcoming internal format is *xhtml2* (not xhtml).
Second we have already the xdocs plugin that is transforming
Third it is preparing *skins* to a transition to xhtml as input format
(as I understood the code example you have send).

How I understood your idea it seems that it is "just" a way to extract
the body of a html document, right? ...and it is not transforming it to
an internal format, or?

Like said I may have not understood your suggestion right.

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

I cannot find the thread about it anymore, but yeah, we decided to
normalize and harmonize this matching. 

There are lot of problems with the **-body*.html ( patterns.

Thorsten Scherler
COO Spain
Wyona Inc.  -  Open Source Content Management  -  Apache Lenya               

View raw message