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 xdocs-to-xhtml2. 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 (et.al.) patterns. salu2 -- Thorsten Scherler COO Spain Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED] [EMAIL PROTECTED]
