forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: Implementing direct html-support
Date Thu, 04 May 2006 02:21:04 GMT
Thorsten Scherler wrote:
> Ferdinand Soethe escribi??:
> > Thorsten Scherler wrote:
> > >Ferdinand Soethe escribi??:
> > >
> > >> 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. 

There was a big discussion recently about this, on the
user@ list i think. If you try to over-ride parts of the
core sitemap with your project sitemap, then you also
need to handle other parts of the core. Messy.

Input plugins or perhaps internal plugins are the
way to go.

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

My first reaction when reading Ferdinand's original mail
was that it should be an input plugin.

Step 2 of our "Apache Forrest 1.0 specification (Working Draft)"
localhost:8888/TR/2005/WD-forrest10.html#Processing+pipeline
"Transform the main source to the intermediate format, XHTML2.
The various input formats are handled by specific input plugins,
all transforming to XHTML2. Input plugins for HTML and XHTML
are available by default."

We really should get that out of draft state.

-David

Mime
View raw message