You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ferdinand Soethe <fe...@apache.org> on 2006/05/02 11:45:35 UTC
Implementing direct html-support
I'v finally started to implement direct support for html (as a first
step towards xhtml as core format).
To do so I have written a direct transformation from html to
body-*.html and inserted it into my project sitemap (Forrest 0.7x)
like this
<map:match pattern="**body-*.html">
<map:select type="exists">
<map:when test="{project:content.xdocs}{1}{2}.html">
<map:generate type="html" src="{project:content.xdocs}{1}{2}.html" />
<map:transform type="xinclude"/>
<map:transform type="linkrewriter" src="cocoon:/{1}linkmap-{2}.html"/>
<map:transform src="{forrest:stylesheets}/declare-broken-site-links.xsl" />
<map:transform src="{project:resources.stylesheets}/html-to-body.xsl" />
<map:serialize type="xml" />
</map:when>
</map:select>
</map:match>
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.
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?
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?
(Naturally the stylesheet would have to go in
{forrest:stylesheets} instead.
Thanks,
Ferdinand
--
Ferdinand Soethe
Re: Implementing direct html-support
Posted by David Crossley <cr...@apache.org>.
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
Re: Implementing direct html-support
Posted by Thorsten Scherler <th...@wyona.com>.
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
thorsten.scherler@wyona.com thorsten@apache.org
Re: Implementing direct html-support
Posted by Ferdinand Soethe <fe...@apache.org>.
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
Re: Implementing direct html-support
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 02-05-2006 a las 11:45 +0200, Ferdinand Soethe escribió:
> I'v finally started to implement direct support for html (as a first
> step towards xhtml as core format).
>
> To do so I have written a direct transformation from html to
> body-*.html and inserted it into my project sitemap (Forrest 0.7x)
> like this
>
> <map:match pattern="**body-*.html">
> <map:select type="exists">
> <map:when test="{project:content.xdocs}{1}{2}.html">
> <map:generate type="html" src="{project:content.xdocs}{1}{2}.html" />
> <map:transform type="xinclude"/>
> <map:transform type="linkrewriter" src="cocoon:/{1}linkmap-{2}.html"/>
> <map:transform src="{forrest:stylesheets}/declare-broken-site-links.xsl" />
> <map:transform src="{project:resources.stylesheets}/html-to-body.xsl" />
> <map:serialize type="xml" />
> </map:when>
> </map:select>
> </map:match>
>
>
> 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.
>
> 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?
>
> 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).
In the dispatcher we are now using extensions like **.body.xml which are
conform to our naming conventions.
wdot?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Implementing direct html-support
Posted by Ferdinand Soethe <fe...@apache.org>.
Just for the record in case somebody else stumbles over this one (and
in reply to my own horribly misspelled question):
> I'v finally started to implement direct support for html (as a first
> step towards xhtml as core format).
> To do so I have written a direct transformation from html to
> body-*.html and inserted it into my project sitemap (Forrest 0.7x)
> like this
> <map:match pattern="**body-*.html">
> <map:select type="exists">
> <map:when test="{project:content.xdocs}{1}{2}.html">
> <map:generate type="html"
> src="{project:content.xdocs}{1}{2}.html" />
> <map:transform type="xinclude"/>
> <map:transform type="linkrewriter"
> src="cocoon:/{1}linkmap-{2}.html"/>
> <map:transform
> src="{forrest:stylesheets}/declare-broken-site-links.xsl" />
> <map:transform
> src="{project:resources.stylesheets}/html-to-body.xsl" />
> <map:serialize type="xml" />
> </map:when>
> </map:select>
> </map:match>
> 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.
The problem is this reference to the linkmap
<map:transform type="linkrewriter" src="cocoon:/{1}linkmap-{2}.html"/>
which uses the cocoon-protocol. It doesn't work because 'cocoon:/'
means 'look for a match in the current sitemap' which is my project
sitymap and doesn't habe such a match. So I get the proper error
message 'No pipeline matched request: linkmap-anmeldung.html'
Replace this with
<map:transform type="linkrewriter" src="cocoon://{1}linkmap-{2}.html"/>
referencing it the parent sitemap everything works just fine.
--
Ferdinand Soethe