You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Sjur Moshagen <sj...@mac.com> on 2006/09/14 14:26:29 UTC
i18n/dispatcher: language selection contract
Hello,
I'm trying to make my first dispatcher contract. It turned out to be
more problematic than I first thought, problems below the pseudocode.
Here's what I want to do: I want to create a language selection list
for a multilingual site. The language selection list should be
dynamically generated for each document, since it isn't known which
document have more than one language, and which languages are
available for each document. The pseudocode goes like this:
1- get the request
2- get a list of all documents that matches the request, disregarding
i18n infixes in the
filenames (that is, a request for X.html should match all of:
X.YY.xml
X.ZZ.xml
X.xml
where YY, ZZ and <nothing> corresponds to available locales or
the fallback file
3- examine the X.xml (fallback file) for an @xml:lang or @lang to
determine the
language of the document; if not found, use the site default (if
available)
4- based on 2 and 3, create a list of all languages available
5- examine the document actually being returned by the request for
@xml:lang or @lang,
to be able to detect the currently viewed language (it could be
different from
the fallback document, since other i18n components can have
picked a better
choice based on browser settings)
6- return a list of available language variants, tagging the
presently displayed
language, and with each of the other languages as a link to that
document (using,
e.g. ?locale=YY or some other means to override browser settings)
The list should be formatted with CSS to whatever is wanted. My
present goal is to have a simple horisontal list across the page,
between the menu on the left and the PDF icon on the right, just
above the document title.
Problem #1:
I can't get the contract to do anything!
I have in my {$project}/resources/themes/pelt.fv the following snippet:
<forrest:hook class="languages">TEST
<forrest:contract name="language-variants" />
</forrest:hook>
but it only returns an empty
<div class="languages"/>
for the hook. The first version of the contract, located in
{$project}/resources/themes/common/html/language-variants.ft,
contains the following:
<?xml version="1.0" encoding="UTF-8"?>
<forrest:contract
xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
xmlns:forrest="http://apache.org/forrest/templates/1.0"
name="language-variants">
<description>
<p>
<strong>language-variants</strong> will output a list of
available language for a given
input document. The presently displayed language will be marked.
Styling
is done using CSS.
</p>
</description>
<usage><![CDATA[<forrest:contract name="language-variants"
dataURI="cocoon://#{$getRequest}.languages.xml"/>]]></usage>
<forrest:template xmlns:forrest="http://apache.org/forrest/
templates/1.0"
name="language-variants" inputFormat="xsl">
<xsl:stylesheet version="1.1"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
debug string -
<forrest:content>
<forrest:part>
<xsl:comment>+ |start language list +</xsl:comment>
<div class="language-variants">
SME
</div>
<xsl:comment>+ |end language list +</xsl:comment>
</forrest:part>
</forrest:content>
</xsl:template>
</xsl:stylesheet>
</forrest:template>
</forrest:contract>
I would hve expected it to output "SME", but nothing shows up.
I have tried to read and follow the instructions at:
http://forrest.apache.org/docs_0_80/howto/howto-structurer-
contracts.html
and related pages linked to at the bottom.
Any guidance would be greatly appreciated!
Best regards,
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 20. sep. 2006 kl. 11.41 skrev Thorsten Scherler:
>> Now it is only the last finishing touches: CSS + some i18n of the
>> menu itself. This is fun!
>>
>
> :)
The fun ended there :-/ - I couldn't get the i18n of the menu/
language list itself to work. What you get is a list of language
codes, which are links to the corresponding language version of the
doc. Ok for inhouse testing, but not good on end users.
The CSS is bare-bones - it only moves the language list to the right
of the menu.
> Cheers for your feedback Sjur and cheers for testing/working with the
> dispatcher. We would very much like the code that you have
> developed in
> our dis (if you can contribute it to our issue tracker). That would be
> awesome.
>
> TIA ;)
I can provide what I have right away. Actually, I would prefer to do
that, and let some of you figure out the best locations for the files
(I have done all development in the project tree, thus no proper patch).
Would that be ok?
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2006-09-20 at 08:27 +0300, Sjur Moshagen wrote:
> Den 20. sep. 2006 kl. 08.20 skrev Sjur Moshagen:
>
> > Den 20. sep. 2006 kl. 08.16 skrev Sjur Moshagen:
> >
> >> Two issues remain:
> >>
> >> 1) How do I get the *full* request URL into my contract, ie #
> >> {$getRequest} + extension in one string? I need this to be able to
> >> return a working URL extended with the override locale setting:
> >>
> >> URL?locale=XY
> >>
> >> 2) There is a bug in the processing of the contract that leads to
> >> a double set of language list. I have confirmed that the bug is
> >> not in my XSL (at least according to xsltproc), thus I can only
> >> blame Forrest/dispatcher;-)
> >
> > Forget about the second issue - I resolved it myself. It was really
> > simple, just removing the forrest: parts of the second template.
> >
> > So - only one issue + some CSS for the contract to be ready:-)
>
> Forget about the first issue as well - by constructing the URL
> extension properly:
>
> ?locale=XY
>
> it is appended to the existing URL somewhere (I don't know), such
> that the result is exactly what it should be!
>
> Yay - I have a *working* language override menu!
>
> Now it is only the last finishing touches: CSS + some i18n of the
> menu itself. This is fun!
>
:)
Cheers for your feedback Sjur and cheers for testing/working with the
dispatcher. We would very much like the code that you have developed in
our dis (if you can contribute it to our issue tracker). That would be
awesome.
TIA ;)
salu2
> Sjur
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 20. sep. 2006 kl. 08.20 skrev Sjur Moshagen:
> Den 20. sep. 2006 kl. 08.16 skrev Sjur Moshagen:
>
>> Two issues remain:
>>
>> 1) How do I get the *full* request URL into my contract, ie #
>> {$getRequest} + extension in one string? I need this to be able to
>> return a working URL extended with the override locale setting:
>>
>> URL?locale=XY
>>
>> 2) There is a bug in the processing of the contract that leads to
>> a double set of language list. I have confirmed that the bug is
>> not in my XSL (at least according to xsltproc), thus I can only
>> blame Forrest/dispatcher;-)
>
> Forget about the second issue - I resolved it myself. It was really
> simple, just removing the forrest: parts of the second template.
>
> So - only one issue + some CSS for the contract to be ready:-)
Forget about the first issue as well - by constructing the URL
extension properly:
?locale=XY
it is appended to the existing URL somewhere (I don't know), such
that the result is exactly what it should be!
Yay - I have a *working* language override menu!
Now it is only the last finishing touches: CSS + some i18n of the
menu itself. This is fun!
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 20. sep. 2006 kl. 08.16 skrev Sjur Moshagen:
> Two issues remain:
>
> 1) How do I get the *full* request URL into my contract, ie #
> {$getRequest} + extension in one string? I need this to be able to
> return a working URL extended with the override locale setting:
>
> URL?locale=XY
>
> 2) There is a bug in the processing of the contract that leads to a
> double set of language list. I have confirmed that the bug is not
> in my XSL (at least according to xsltproc), thus I can only blame
> Forrest/dispatcher;-)
Forget about the second issue - I resolved it myself. It was really
simple, just removing the forrest: parts of the second template.
So - only one issue + some CSS for the contract to be ready:-)
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Hello again,
Den 14. sep. 2006 kl. 15.26 skrev Sjur Moshagen:
> 1- get the request
> 2- get a list of all documents that matches the request,
> disregarding i18n infixes in the
> filenames (that is, a request for X.html should match all of:
> X.YY.xml
> X.ZZ.xml
> X.xml
> where YY, ZZ and <nothing> corresponds to available locales or
> the fallback file
> 3- examine the X.xml (fallback file) for an @xml:lang or @lang to
> determine the
> language of the document; if not found, use the site default (if
> available)
> 4- based on 2 and 3, create a list of all languages available
> 5- examine the document actually being returned by the request for
> @xml:lang or @lang,
> to be able to detect the currently viewed language (it could be
> different from
> the fallback document, since other i18n components can have
> picked a better
> choice based on browser settings)
> 6- return a list of available language variants, tagging the
> presently displayed
> language, and with each of the other languages as a link to that
> document (using,
> e.g. ?locale=YY or some other means to override browser settings)
I have now managed to do 1-5 (not in the exact way described above,
but still...).
I also found an existing component that seems to be doing the same,
but it doesn't work with dispatcher (calling http://localhost:8888/
i18n-index.html returns an error) - see i18n.xmap for details.
Compared with the old version, my implementation improves on a couple
of points:
- it handles fallback documents (ie document.xml as well as
document.XY.xml, where XY is the locale)
- it looks into the fallback document for language markup, and will
use that to determine the language of the fallback document if found
- if no language information for the fallback document is found, it
will use an external default; presently it is hardcoded, but it
should be easy for somebody to replace that with a forrest property
Two issues remain:
1) How do I get the *full* request URL into my contract, ie #
{$getRequest} + extension in one string? I need this to be able to
return a working URL extended with the override locale setting:
URL?locale=XY
2) There is a bug in the processing of the contract that leads to a
double set of language list. I have confirmed that the bug is not in
my XSL (at least according to xsltproc), thus I can only blame
Forrest/dispatcher;-)
Here are the present details (the created URLs are not properly made
yet, disregard that issue, it is simple to fix - just wanted to post
the two main issues):
==== Contract markup in local pelt.fv ====
<forrest:hook class="languages">
<forrest:contract name="language-variants"
dataURI="cocoon://#{$getRequest}.languages.xml">
<!--forrest:property name="URL">cocoon://#{$getRequest}</
forrest:property-->
</forrest:contract>
</forrest:hook>
==== document returned by dataURI above: ====
<?xml version="1.0" encoding="UTF-8"?>
<document localecount="4">
<locale>en</locale>
<locale>nb</locale>
<locale selected="true">se</locale> <!-- this is currently being
displayed -->
<locale fallback="true">en</locale> <!-- this is the 'document.xml'
type file, ie without locale -->
</document>
(The two 'en' locales is caused by us having one document.en.xml and
another document.xml with @xml:lang="en" - two documents for the same
language. That is a miss on our part, and the double locale listing
can be used for debugging.)
==== contract language-variants.ft: ====
<forrest:contract
xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
xmlns:forrest="http://apache.org/forrest/templates/1.0"
name="language-variants">
<description>
<p>
<strong>language-variants</strong> will output a list of
available language for a given
input document. The presently displayed language will be marked.
Styling
is done using CSS.
</p>
</description>
<usage><![CDATA[<forrest:contract name="language-variants"
dataURI="cocoon://#{$getRequest}.languages.xml"/>]]></usage>
<forrest:template xmlns:forrest="http://apache.org/forrest/
templates/1.0"
name="language-variants" inputFormat="xsl"
xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
<xsl:stylesheet version="1.1"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!--xsl:param name="URL" -->
<!--<xsl:param name="defaultVariables" select="'test.html'"/>-->
<!--<xsl:variable name="skin-img-dir"
select="$defaultVariables/*/*[@name='skin-img-dir']/@value"/>-->
<xsl:template match="document">
<forrest:content>
debug string -
<forrest:part>
<xsl:comment>+ |start language list +</xsl:comment>
<xsl:choose>
<xsl:when test="@localecount = 1">
<xsl:comment>+ |no alternative languages +</
xsl:comment>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates select="locale" />
</xsl:otherwise>
</xsl:choose>
<xsl:comment>+ |end language list +</xsl:comment>
</forrest:part>
</forrest:content>
</xsl:template>
<xsl:template match="locale">
<forrest:content>
<forrest:part>
<xsl:choose>
<xsl:when test="@selected = 'true'">
<span class="selected">
<i18n:text><xsl:apply-templates/></i18n:text>
</span>
</xsl:when>
<xsl:otherwise>
<span>
<a>
<xsl:attribute name="href">
<xsl:value-of select="./text()"/>
</xsl:attribute>
<i18n:text><xsl:apply-templates/></i18n:text></a>
</span>
</xsl:otherwise>
</xsl:choose>
</forrest:part>
</forrest:content>
</xsl:template>
</xsl:stylesheet>
</forrest:template>
</forrest:contract>
==== output in rendered html: ====
<div class="languages">
<!--+ |start language list +-->
<content>
<part>
<span>
<a href="en">en</a>
</span>
</part>
</content>
<content>
<part>
<span>
<a href="nb">nb</a>
</span>
</part>
</content>
<content>
<part>
<span class="selected">se</span>
</part>
</content>
<content>
<part>
<span>
<a href="en">en</a>
</span>
</part>
</content>
<!--+ |end language list +-->
<span>
<a href="en">en</a>
</span>
<span>
<a href="nb">nb</a>
</span>
<span class="selected">se</span>
<span>
<a href="en">en</a>
</span>
</div>
==== expected output as rendered by xsltproc (my wrapping/indenting):
====
<?xml version="1.0"?>
<forrest:content xmlns:forrest="http://apache.org/forrest/templates/
1.0" xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
debug string -
<forrest:part>
<!--+ |start language list +-->
<forrest:content>
<forrest:part>
<span><a href="nb">
<i18n:text>nb</i18n:text></a>
</span>
</forrest:part>
</forrest:content>
<forrest:content>
<forrest:part>
<span class="selected">
<i18n:text>se</i18n:text>
</span>
</forrest:part>
</forrest:content>
<forrest:content>
<forrest:part>
<span>
<a href="en"><i18n:text>en</i18n:text></a>
</span>
</forrest:part>
</forrest:content>
<!--+ |end language list +-->
</forrest:part>
</forrest:content>
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 14. sep. 2006 kl. 17.30 skrev Thorsten Scherler:
>> <div class="languages"/>
>
> Meaning the hook get transformed the contract not.
Yepp.
> BTW the TEST is not
> allowed in this position.
Ok.
>>
>> for the hook. The first version of the contract, located in
>> {$project}/resources/themes/common/html/language-variants.ft,
>> contains the following:
>
> Please try requesting:
> http://localhost:8888/resolve.contract.html.language-variants or AFAIR
> for your case
> http://localhost:8889/resolve.contract.html.language-variants Does the
> contract show up?
Yes, no problem here: it returns the contract.
(BTW, I have changed my setup so port # 8888 is fine:-)
> If not, does {lm:themer.project.dir} point to the dir? What does
> http://localhost:8888/ls.contracts.project.html return? Is the
> contract
> listed?
Yes, it is listed.
>> I would hve expected it to output "SME", but nothing shows up.
>
> The contract looks alright. The only thing that you define in the
> usage
> <forrest:contract name="language-variants"
> dataURI="cocoon://#{$getRequest}.languages.xml"/> and in your
> structurer
> <forrest:contract name="language-variants" />. That should not matter
> ATM for the testing but later on you may want to change this in the
> structurer.
I had a more comlex variant in the beginning, but that one failed
(gave me an error message), so I reduced it to something simple that
*should* work, to confirm that my setup is ok. I have no error
message anymore, but no content either:-/
The contract was based on a mixture of blank.ft and content-title.ft
(IIRC), but it is now basically a simplified version of just blank.ft.
> Please report back when you tested the above links and tell us what
> the
> outcome is.
Tested and reported.
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2006-09-14 at 15:26 +0300, Sjur Moshagen wrote:
> Hello,
>
> I'm trying to make my first dispatcher contract. It turned out to be
> more problematic than I first thought, problems below the pseudocode.
>
> Here's what I want to do: I want to create a language selection list
> for a multilingual site. The language selection list should be
> dynamically generated for each document, since it isn't known which
> document have more than one language, and which languages are
> available for each document. The pseudocode goes like this:
>
> 1- get the request
> 2- get a list of all documents that matches the request, disregarding
> i18n infixes in the
> filenames (that is, a request for X.html should match all of:
> X.YY.xml
> X.ZZ.xml
> X.xml
> where YY, ZZ and <nothing> corresponds to available locales or
> the fallback file
> 3- examine the X.xml (fallback file) for an @xml:lang or @lang to
> determine the
> language of the document; if not found, use the site default (if
> available)
> 4- based on 2 and 3, create a list of all languages available
> 5- examine the document actually being returned by the request for
> @xml:lang or @lang,
> to be able to detect the currently viewed language (it could be
> different from
> the fallback document, since other i18n components can have
> picked a better
> choice based on browser settings)
> 6- return a list of available language variants, tagging the
> presently displayed
> language, and with each of the other languages as a link to that
> document (using,
> e.g. ?locale=YY or some other means to override browser settings)
>
> The list should be formatted with CSS to whatever is wanted. My
> present goal is to have a simple horisontal list across the page,
> between the menu on the left and the PDF icon on the right, just
> above the document title.
>
> Problem #1:
>
> I can't get the contract to do anything!
>
> I have in my {$project}/resources/themes/pelt.fv the following snippet:
>
> <forrest:hook class="languages">TEST
> <forrest:contract name="language-variants" />
> </forrest:hook>
>
> but it only returns an empty
>
> <div class="languages"/>
Meaning the hook get transformed the contract not. BTW the TEST is not
allowed in this position.
>
> for the hook. The first version of the contract, located in
> {$project}/resources/themes/common/html/language-variants.ft,
> contains the following:
Please try requesting:
http://localhost:8888/resolve.contract.html.language-variants or AFAIR
for your case
http://localhost:8889/resolve.contract.html.language-variants Does the
contract show up?
If not, does {lm:themer.project.dir} point to the dir? What does
http://localhost:8888/ls.contracts.project.html return? Is the contract
listed?
>
> <?xml version="1.0" encoding="UTF-8"?>
> <forrest:contract
> xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
> xmlns:forrest="http://apache.org/forrest/templates/1.0"
> name="language-variants">
>
> <description>
> <p>
> <strong>language-variants</strong> will output a list of
> available language for a given
> input document. The presently displayed language will be marked.
> Styling
> is done using CSS.
> </p>
> </description>
> <usage><![CDATA[<forrest:contract name="language-variants"
> dataURI="cocoon://#{$getRequest}.languages.xml"/>]]></usage>
> <forrest:template xmlns:forrest="http://apache.org/forrest/
> templates/1.0"
> name="language-variants" inputFormat="xsl">
> <xsl:stylesheet version="1.1"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> <xsl:template match="/">
> debug string -
> <forrest:content>
> <forrest:part>
> <xsl:comment>+ |start language list +</xsl:comment>
> <div class="language-variants">
> SME
> </div>
> <xsl:comment>+ |end language list +</xsl:comment>
> </forrest:part>
> </forrest:content>
> </xsl:template>
> </xsl:stylesheet>
> </forrest:template>
> </forrest:contract>
>
> I would hve expected it to output "SME", but nothing shows up.
The contract looks alright. The only thing that you define in the usage
<forrest:contract name="language-variants"
dataURI="cocoon://#{$getRequest}.languages.xml"/> and in your structurer
<forrest:contract name="language-variants" />. That should not matter
ATM for the testing but later on you may want to change this in the
structurer.
> I have tried to read and follow the instructions at:
>
> http://forrest.apache.org/docs_0_80/howto/howto-structurer-
> contracts.html
>
> and related pages linked to at the bottom.
>
> Any guidance would be greatly appreciated!
Please report back when you tested the above links and tell us what the
outcome is.
salu2
>
> Best regards,
> Sjur
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 15. sep. 2006 kl. 17.50 skrev Thorsten Scherler:
> On Fri, 2006-09-15 at 13:37 +0300, Sjur Moshagen wrote:
>
>> Conclusion: the XSL can't be found. What should the locationmap entry
>>
>> <location src="{properties:resources}stylesheets/xslt/xml/document-
>> to-
>> {1}.xsl"/>
>>
>> be resolved to?
>
> hmm, *normally* to the location you had, but ...
>
>>
>> I eventually replaced the locationmap loookup in the project sitemap
>> with the following:
>>
>> <map:transform src="{properties:resources.stylesheets}/
>> document-to-languages.xsl" />
>
> that is not the same as above since the .../xml/... is not in the
> path.
I known, see below.
> If you have not moved the file then the first file had not the right
> location.
>
> {properties:resources}stylesheets/xslt ==
> {properties:resources.stylesheets}
Here is what I tried with the LM lookup, NONE of which were found by
the LM:
src/documentation/resources/stylesheets/xslt/xml/
src/documentation/resources/stylesheets/xslt/
src/documentation/resources/stylesheets/
src/documentation/resources/
> Maybe we should update the dispatcher lm to shorten the location a wee
> bit.
I don't mind nested folders, as long as it works:-)
>> and it was found. Bad thing I couldn't get the locationmap working.
>
> The error you reported have been (like yourself note here) related to
> the locationmap lookup. I am not sure anymore whether the first try
> had
> the right path.
>
> Anyway you made it work. :) Good on ya mate.
:-)
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2006-09-15 at 13:37 +0300, Sjur Moshagen wrote:
...
> > and see what is gives, if it returns something then try
> >
> > <map:pipeline>
> > <map:match pattern="**.languages.xml">
> > <map:generate src="{lm:dataModel-xml-document-to-
> > languages.xsl}" />
> > <map:serialize />
> > </map:match>
> > </map:pipeline>
> >
> > If this works then the xsl itself maybe corrupt.
>
> It doesn't work, it returns:
>
> Message: Resource Not Found
>
> Description: The requested resource "/index.languages.xml" could not
> be found
>
> Sender: org.apache.cocoon.servlet.CocoonServlet
>
>
> And in the log (core.log):
>
> WARN (2006-09-15) 12:38.53:058 [core.manager] (/
> index.languages.xml) PoolThread-1/CoreServiceManager: disposing of
> handler for unreleased component. role
> [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo]
> WARN (2006-09-15) 12:38.53:083 [access] (/index.languages.xml)
> PoolThread-1/CocoonServlet: Resource not found.
> at <map:serialize> - file:/Users/sjur/Documents/i18n/sd/src/
> documentation/sitemap.xmap:56:26
> at <map:generate> - file:/Users/sjur/Documents/i18n/sd/src/
> documentation/sitemap.xmap:55:76
> at <map:mount> - file:/usr/local/forrest/main/webapp/
> sitemap.xmap:396:48
>
> Conclusion: the XSL can't be found. What should the locationmap entry
>
> <location src="{properties:resources}stylesheets/xslt/xml/document-to-
> {1}.xsl"/>
>
> be resolved to?
hmm, *normally* to the location you had, but ...
>
> I eventually replaced the locationmap loookup in the project sitemap
> with the following:
>
> <map:transform src="{properties:resources.stylesheets}/
> document-to-languages.xsl" />
that is not the same as above since the .../xml/... is not in the path.
If you have not moved the file then the first file had not the right
location.
{properties:resources}stylesheets/xslt ==
{properties:resources.stylesheets}
Maybe we should update the dispatcher lm to shorten the location a wee
bit.
>
> and it was found. Bad thing I couldn't get the locationmap working.
The error you reported have been (like yourself note here) related to
the locationmap lookup. I am not sure anymore whether the first try had
the right path.
Anyway you made it work. :) Good on ya mate.
>
> Thanks for helping!
de nada, was a pleasure.
>
> On to the next step:-)
Reading your first mail again it seems you still have some work in front
of you. Do not hesitate to ask on this list. On the weekend I need to go
to the office to finish a presentation I have next week and I will check
my mails. If not I will do so on monday.
salu2
>
> Sjur
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 19. sep. 2006 kl. 03.51 skrev David Crossley:
> Perhaps you need to declare the DirectoryGenerator in your project
> sitemap.
Sorry for this stupid mistake - should have checked that first:-(
After I declared the DirectoryGenerator, it works as it should. Thanks!
Sjur
Re: i18n/dispatcher: language selection contract
Posted by David Crossley <cr...@apache.org>.
Sjur Moshagen wrote:
> skrev Sjur Moshagen:
>
> >1) it would be nice if it could return all available locales for
> >the matching document in a sitemap parameter. As it is now, I need
> >to do some sitemap magic to aggregate the list of all candidate
> >documents, then process the aggregation and finally deliver the
> >result. This is error prone and slow, compared to returning a list
> >of found documents by a Java component that needs to do the job
> >anyway.
>
> That sitemap magic wasn't that easy:-(
>
> The idea was to use the directory generator to get a listing of all
> files matching the pattern {RequestDoc}.{Locale}.{Extension}.
>
> The bad thing is that it does not seem the directory generator is
> included in Forrest:
>
> Internal Server Error
>
> Message: null
>
> Description: No details available.
>
> Sender: org.apache.cocoon.servlet.CocoonServlet
>
> Source: Cocoon Servlet
>
> Request URI
>
> index.languages.xml
> cause
>
> Type 'directory' does not exist for 'map:generate' at file:/Users/
> sjur/Documents/i18n/sd/src/documentation/sitemap.xmap:97:52
> request-uri
>
> /index.languages.xml
>
>
> The directory generator would have given me a nice xml snippet
> containing all and only localised file, from which I easily could
> have extracted the needed info. Any suggestions on an alternative route?
Perhaps you need to declare the DirectoryGenerator in your project
sitemap. See examples in main/webapp/revisions.xmap and i18n.xmap
-David
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 18. sep. 2006 kl. 14.32 skrev Sjur Moshagen:
> 1) it would be nice if it could return all available locales for
> the matching document in a sitemap parameter. As it is now, I need
> to do some sitemap magic to aggregate the list of all candidate
> documents, then process the aggregation and finally deliver the
> result. This is error prone and slow, compared to returning a list
> of found documents by a Java component that needs to do the job
> anyway.
That sitemap magic wasn't that easy:-(
The idea was to use the directory generator to get a listing of all
files matching the pattern {RequestDoc}.{Locale}.{Extension}.
The bad thing is that it does not seem the directory generator is
included in Forrest:
Internal Server Error
Message: null
Description: No details available.
Sender: org.apache.cocoon.servlet.CocoonServlet
Source: Cocoon Servlet
Request URI
index.languages.xml
cause
Type 'directory' does not exist for 'map:generate' at file:/Users/
sjur/Documents/i18n/sd/src/documentation/sitemap.xmap:97:52
request-uri
/index.languages.xml
The directory generator would have given me a nice xml snippet
containing all and only localised file, from which I easily could
have extracted the needed info. Any suggestions on an alternative route?
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 18. sep. 2006 kl. 13.56 skrev Thorsten Scherler:
>> This snippet does not work (slightly more complex matching):
>>
>> <map:pipeline>
>> <map:match pattern="**/*.languages.xml">
>> <map:generate src="cocoon://{1}/{2}.xml" />
>
> This should work in all sub dir. Meaning
> {$xdocs}/index.de.xml will not match since there is no "/" in the
> path.
> {$xdocs}/sample/index.de.xml should match.
Thanks for the clarification. That explained it:-)
>> This neither (simple matching followed by i18n matching):
>>
>> <map:pipeline>
>> <map:match pattern="**.languages.xml">
>> <map:match type="i18n" pattern="{1}.*.xml">
>
> Never used the <map:match type="i18n"/> Can you point us to the docu?
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/matching/
LocaleMatcher.html
It is configured in the main sitemap.
I have used it earlier in a Cocoon-based project, and it works
(almost) like a charm. For this contract I have one feature request,
though:
1) it would be nice if it could return all available locales for the
matching document in a sitemap parameter. As it is now, I need to do
some sitemap magic to aggregate the list of all candidate documents,
then process the aggregation and finally deliver the result. This is
error prone and slow, compared to returning a list of found documents
by a Java component that needs to do the job anyway.
2) The other feature I would like to add is a sitemap parameter
containing the default locale, if specified in the matcher config.
Imagine a set of documents written in one of the supported wiki formats:
text.de.jspwiki
text.nn.jspwiki
text.jspwiki
The input is text only, thus there's no way we can tag the content of
the last file for which language it contains. Now, for a user being
served the .de. variant, how do I tell her what other languages are
available? Presently there's no way other than hard-coding the
default language somewhere (or provide a forrest variable), where I
could just have asked the LocaleMatcher for the value, if it had been
provided to me.
(A forrest variable would probably be nice anyway, but does not
remove the need for having access to the default locale in the sitemap.)
Most of the above should probably have been directed to one of the
Cocoon lists, but I'm not on any of them (have been, but too much
irrelevant traffic for me). Both of the requests above should be easy
to implement, though, so perhaps some of the Forrest devs have the
possiblitity to do it?
Best regards,
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2006-09-18 at 13:32 +0300, Sjur Moshagen wrote:
> Den 15. sep. 2006 kl. 13.37 skrev Sjur Moshagen:
>
> > On to the next step:-)
>
> In the project sitemap, I'm trying to match on the filename and the
> locale, none of which works. The following sitemap snippet works:
>
> <map:pipeline>
> <map:match pattern="**.languages.xml">
> <map:generate src="cocoon://{1}.xml" />
> <map:transform src="{properties:resources.stylesheets}/
> document-to-languages.xsl" />
> <map:serialize encoding="UTF-8" type="xml"/>
> </map:match>
> </map:pipeline>
>
>
> This snippet does not work (slightly more complex matching):
>
> <map:pipeline>
> <map:match pattern="**/*.languages.xml">
> <map:generate src="cocoon://{1}/{2}.xml" />
This should work in all sub dir. Meaning
{$xdocs}/index.de.xml will not match since there is no "/" in the path.
{$xdocs}/sample/index.de.xml should match.
> <map:transform src="{properties:resources.stylesheets}/
> document-to-languages.xsl" />
> <map:serialize encoding="UTF-8" type="xml"/>
> </map:match>
> </map:pipeline>
>
> This neither (simple matching followed by i18n matching):
>
> <map:pipeline>
> <map:match pattern="**.languages.xml">
> <map:match type="i18n" pattern="{1}.*.xml">
Never used the <map:match type="i18n"/> Can you point us to the docu?
Need to go now.
salu2
> <map:generate src="cocoon://{../1}.xml" />
> <map:transform src="{properties:resources.stylesheets}/
> document-to-languages.xsl" />
> <map:serialize encoding="UTF-8" type="xml"/>
> </map:match>
> </map:match>
> </map:pipeline>
>
>
> Both the last two sitemaps causes the following error:
>
> Resource Not Found
>
> Message: Resource Not Found
>
> Description: The requested resource "/index.languages.xml" could not
> be found
>
> Sender: org.apache.cocoon.servlet.CocoonServlet
>
> Source: Cocoon Servlet
>
> Apache Cocoon 2.2.0-dev
>
>
>
> I can't see what I'm doing wrong here. Both the failing snippets
> should be standard and straightforward matching.
>
> Sjur
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 15. sep. 2006 kl. 13.37 skrev Sjur Moshagen:
> On to the next step:-)
In the project sitemap, I'm trying to match on the filename and the
locale, none of which works. The following sitemap snippet works:
<map:pipeline>
<map:match pattern="**.languages.xml">
<map:generate src="cocoon://{1}.xml" />
<map:transform src="{properties:resources.stylesheets}/
document-to-languages.xsl" />
<map:serialize encoding="UTF-8" type="xml"/>
</map:match>
</map:pipeline>
This snippet does not work (slightly more complex matching):
<map:pipeline>
<map:match pattern="**/*.languages.xml">
<map:generate src="cocoon://{1}/{2}.xml" />
<map:transform src="{properties:resources.stylesheets}/
document-to-languages.xsl" />
<map:serialize encoding="UTF-8" type="xml"/>
</map:match>
</map:pipeline>
This neither (simple matching followed by i18n matching):
<map:pipeline>
<map:match pattern="**.languages.xml">
<map:match type="i18n" pattern="{1}.*.xml">
<map:generate src="cocoon://{../1}.xml" />
<map:transform src="{properties:resources.stylesheets}/
document-to-languages.xsl" />
<map:serialize encoding="UTF-8" type="xml"/>
</map:match>
</map:match>
</map:pipeline>
Both the last two sitemaps causes the following error:
Resource Not Found
Message: Resource Not Found
Description: The requested resource "/index.languages.xml" could not
be found
Sender: org.apache.cocoon.servlet.CocoonServlet
Source: Cocoon Servlet
Apache Cocoon 2.2.0-dev
I can't see what I'm doing wrong here. Both the failing snippets
should be standard and straightforward matching.
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 15. sep. 2006 kl. 11.37 skrev Thorsten Scherler:
>> - the dataURI is looked up separately, and the returned data is
>> served as an argument (XML snippet) to the contract,
>
> well to be 100% correct: if a dataURI is defined this src is used
> as the
> input doc to the xsl transformation (where the contract is the source
> for the xsl). The properties are parsed as parameter. If no dataURI is
> defined we create a <foo/> document in the dispatcher as input doc to
> trigger the transformation.
Ok, thanks for the clarification.
>> From what I can see, it isn't able to resolve the stylesheet OR the
>> source document for some reason.
>
> The source document: "org.apache.excalibur.source.SourceException:
> Cannot get input stream for cocoon://index.languages.xml"
>
>
> What does localhost:8888/index.languages.xml return (this will be the
> testing url for the next steps)? Reading the dispatcherError I
> guess it
> will return nothing.
It returned a similar error message:
Request URI
index.languages.xml
cause
/Users/sjur/Documents/i18n/sd/src/documentation (No such file or
directory)
> To debug what exactly cannot be found try:
> <map:pipeline>
> <map:match pattern="**.languages.xml">
> <map:generate src="cocoon://{1}.xml" />
> <map:serialize />
> </map:match>
> </map:pipeline>
>
> If this returns the document then the xsl cannot be found.
It does return the document, thus it is the XSL that cannot be found.
> To verify put
> again the xsl into the pipe and see the log. There should be then an
> exception telling you where cocoon tried to get the xsl from.
What I get is:
ERROR (2006-09-15) 12:32.30:888 [access] (/index.languages.xml)
PoolThread-1/CocoonServlet: Internal Cocoon Problem
org.apache.cocoon.ProcessingException: Unable to get transformer
handler for file:/Users/sjur/Documents/i18n/sd/src/documentation/
at <map:serialize> - file:/Users/sjur/Documents/i18n/sd/src/
documentation/sitemap.xmap:56:26
at <map:transform> - file:/Users/sjur/Documents/i18n/sd/src/
documentation/sitemap.xmap:55:77
at <map:generate> - file:/Users/sjur/Documents/i18n/sd/src/
documentation/sitemap.xmap:54:48
at <map:mount> - file:/usr/local/forrest/main/webapp/
sitemap.xmap:396:48
at org.apache.cocoon.transformation.TraxTransformer.setup
(TraxTransformer.java:338)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPi
peline(AbstractProcessingPipeline.java:354)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe
line.setupPipeline(AbstractCachingProcessingPipeline.java:614)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.prepare
Pipeline(AbstractProcessingPipeline.java:459)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process
(AbstractProcessingPipeline.java:409)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(
SerializeNode.java:137)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:55)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i
nvoke(PreparableMatchNode.java:116)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
(PipelineNode.java:155)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(
PipelinesNode.java:95)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:292)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:223)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process
(TreeProcessor.java:289)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke
(MountNode.java:114)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke
(SelectNode.java:81)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
(PipelineNode.java:155)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.
invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(
PipelinesNode.java:95)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:292)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:223)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process
(TreeProcessor.java:289)
at org.apache.cocoon.Cocoon.process(Cocoon.java:557)
at org.apache.cocoon.servlet.CocoonServlet.service
(CocoonServlet.java:364)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:354)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch
(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1808)
at org.mortbay.jetty.servlet.WebApplicationContext.handle
(WebApplicationContext.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1758)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at org.mortbay.http.HttpConnection.service
(HttpConnection.java:790)
at org.mortbay.http.HttpConnection.handleNext
(HttpConnection.java:952)
at org.mortbay.http.HttpConnection.handle
(HttpConnection.java:807)
at org.mortbay.http.SocketListener.handleConnection
(SocketListener.java:197)
at org.mortbay.util.ThreadedServer.handle
(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run
(ThreadPool.java:501)
Caused by: org.apache.excalibur.xml.xslt.XSLTProcessorException:
Exception when creating Transformer from file:/Users/sjur/Documents/
i18n/sd/src/documentation/
at
org.apache.cocoon.components.xslt.TraxProcessor.getTransformerHandlerAnd
Validity(TraxProcessor.java:290)
at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.handler.PoolableComponentHandler
$ProxyHandler.invoke(PoolableComponentHandler.java:147)
at $Proxy3.getTransformerHandlerAndValidity(Unknown Source)
at org.apache.cocoon.transformation.TraxTransformer.setup
(TraxTransformer.java:330)
... 40 more
Caused by: org.apache.excalibur.source.SourceNotFoundException: file:/
Users/sjur/Documents/i18n/sd/src/documentation/ doesn't exist.
at org.apache.excalibur.source.impl.FileSource.getInputStream
(FileSource.java:150)
at
org.apache.cocoon.components.xslt.TraxProcessor.sourceToSAX
(TraxProcessor.java:298)
at
org.apache.cocoon.components.xslt.TraxProcessor.getTransformerHandlerAnd
Validity(TraxProcessor.java:239)
... 46 more
Caused by: java.io.FileNotFoundException: /Users/sjur/Documents/i18n/
sd/src/documentation
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at org.apache.excalibur.source.impl.FileSource.getInputStream
(FileSource.java:146)
... 48 more
> I normally do the
> cat ${exceptionLocation}
? Do you mean (in my case):
cat /Users/sjur/Documents/i18n/sd/src/documentation
> and see what is gives, if it returns something then try
>
> <map:pipeline>
> <map:match pattern="**.languages.xml">
> <map:generate src="{lm:dataModel-xml-document-to-
> languages.xsl}" />
> <map:serialize />
> </map:match>
> </map:pipeline>
>
> If this works then the xsl itself maybe corrupt.
It doesn't work, it returns:
Message: Resource Not Found
Description: The requested resource "/index.languages.xml" could not
be found
Sender: org.apache.cocoon.servlet.CocoonServlet
And in the log (core.log):
WARN (2006-09-15) 12:38.53:058 [core.manager] (/
index.languages.xml) PoolThread-1/CoreServiceManager: disposing of
handler for unreleased component. role
[org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo]
WARN (2006-09-15) 12:38.53:083 [access] (/index.languages.xml)
PoolThread-1/CocoonServlet: Resource not found.
at <map:serialize> - file:/Users/sjur/Documents/i18n/sd/src/
documentation/sitemap.xmap:56:26
at <map:generate> - file:/Users/sjur/Documents/i18n/sd/src/
documentation/sitemap.xmap:55:76
at <map:mount> - file:/usr/local/forrest/main/webapp/
sitemap.xmap:396:48
Conclusion: the XSL can't be found. What should the locationmap entry
<location src="{properties:resources}stylesheets/xslt/xml/document-to-
{1}.xsl"/>
be resolved to?
I eventually replaced the locationmap loookup in the project sitemap
with the following:
<map:transform src="{properties:resources.stylesheets}/
document-to-languages.xsl" />
and it was found. Bad thing I couldn't get the locationmap working.
Thanks for helping!
On to the next step:-)
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Thorsten Scherler <th...@wyona.com>.
On Fri, 2006-09-15 at 10:58 +0300, Sjur Moshagen wrote:
> Den 15. sep. 2006 kl. 08.14 skrev Sjur Moshagen:
>
> > With the correction you made above, I get the same result as you -
> > it works!
Nice work Gav and Sjur.
> >
> > Thanks so far, I will now continue with the next step. I'm certain
> > I will be back with more questions soon:-)
>
> So here it comes:-)
>
> I got the simple version to work, now I would like to extract some
> info based on the requested document. I thus changed the pelt.fv hook
> to this:
>
> <forrest:hook class="languages">
> <forrest:contract name="language-variants"
> dataURI="cocoon://#{$getRequest}.languages.xml"/>
> </forrest:hook>
>
> Notice the @dataURI I've added.
>
> I *think* I understand what's going on - here's what I believe,
> please verify or correct any misconception:
>
> - the dataURI is looked up separately, and the returned data is
> served as an argument (XML snippet) to the contract,
well to be 100% correct: if a dataURI is defined this src is used as the
input doc to the xsl transformation (where the contract is the source
for the xsl). The properties are parsed as parameter. If no dataURI is
defined we create a <foo/> document in the dispatcher as input doc to
trigger the transformation.
> to do whatever
> more is needed
>
> I have found matches for cocoon://**.title.xml, and copied it to my
> local sitemap, and modified it:
>
> In src/documentation/sitemap.xmap:
>
> <map:pipeline>
> <map:match pattern="**.languages.xml">
> <map:generate src="cocoon://{1}.xml" />
> <map:transform src="{lm:dataModel-xml-document-to-
> languages.xsl}" />
> <map:serialize />
> </map:match>
> </map:pipeline>
>
> This should give me the source document, which is transformed with
> the specified stylesheet. I have the following in:
>
> src/documentation/resources/stylesheets/xslt/xml/document-to-
> languages.xsl
>
> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/
> Transform">
> <!-- Template to generate the document language -->
> <xsl:template match="document">
> <xsl:choose>
> <xsl:when test="@xml:lang">
> <xsl:copy-of select="@xml:lang"/>
> </xsl:when>
> <xsl:otherwise>
> <title>*No* language found</title>
> </xsl:otherwise>
> </xsl:choose>
>
> </xsl:template>
> </xsl:stylesheet>
>
>
> which I think the locationmap should be able to resolv, based on the
> following snippet in plugins/o.a.f.plugin.internal.dispatcher/
> locationmap.xml:
>
> <match pattern="dataModel-xml-document-to-**.xsl">
> <select type="exists">
> <location
> src="{properties:resources}stylesheets/xslt/xml/
> document-to-{1}.xsl"
> />
> <location
> src="{lm:std-dataModel-xml-document-to-{1}.xsl}"
> />
> </select>
> </match>
>
> With all this, and without changing the contract from what was
> working earlier, I get the following error:
>
> Internal Server Error
>
> Message: null
>
> Description: No details available.
>
> Sender: org.apache.cocoon.servlet.CocoonServlet
>
> Source: Cocoon Servlet
>
> Request URI
>
> index.html
> cause
>
> dispatcherError: 500 - Internal server error
> The contract "language-variants" has thrown thrown an exception by
> resolving raw data from "cocoon://index.languages.xml".
>
> dispatcherErrorStack:
> org.apache.excalibur.source.SourceException: Cannot get input
> stream for cocoon://index.languages.xml
> request-uri
>
> /index.html;jsessionid=3anfa8koll7k8
> Apache Cocoon 2.2.0-dev
>
>
>
> From what I can see, it isn't able to resolve the stylesheet OR the
> source document for some reason.
The source document: "org.apache.excalibur.source.SourceException:
Cannot get input stream for cocoon://index.languages.xml"
What does localhost:8888/index.languages.xml return (this will be the
testing url for the next steps)? Reading the dispatcherError I guess it
will return nothing.
To debug what exactly cannot be found try:
<map:pipeline>
<map:match pattern="**.languages.xml">
<map:generate src="cocoon://{1}.xml" />
<map:serialize />
</map:match>
</map:pipeline>
If this returns the document then the xsl cannot be found. To verify put
again the xsl into the pipe and see the log. There should be then an
exception telling you where cocoon tried to get the xsl from.
I normally do the
cat ${exceptionLocation}
and see what is gives, if it returns something then try
<map:pipeline>
<map:match pattern="**.languages.xml">
<map:generate src="{lm:dataModel-xml-document-to-
languages.xsl}" />
<map:serialize />
</map:match>
</map:pipeline>
If this works then the xsl itself maybe corrupt.
HTH
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: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 15. sep. 2006 kl. 08.14 skrev Sjur Moshagen:
> With the correction you made above, I get the same result as you -
> it works!
>
> Thanks so far, I will now continue with the next step. I'm certain
> I will be back with more questions soon:-)
So here it comes:-)
I got the simple version to work, now I would like to extract some
info based on the requested document. I thus changed the pelt.fv hook
to this:
<forrest:hook class="languages">
<forrest:contract name="language-variants"
dataURI="cocoon://#{$getRequest}.languages.xml"/>
</forrest:hook>
Notice the @dataURI I've added.
I *think* I understand what's going on - here's what I believe,
please verify or correct any misconception:
- the dataURI is looked up separately, and the returned data is
served as an argument (XML snippet) to the contract, to do whatever
more is needed
I have found matches for cocoon://**.title.xml, and copied it to my
local sitemap, and modified it:
In src/documentation/sitemap.xmap:
<map:pipeline>
<map:match pattern="**.languages.xml">
<map:generate src="cocoon://{1}.xml" />
<map:transform src="{lm:dataModel-xml-document-to-
languages.xsl}" />
<map:serialize />
</map:match>
</map:pipeline>
This should give me the source document, which is transformed with
the specified stylesheet. I have the following in:
src/documentation/resources/stylesheets/xslt/xml/document-to-
languages.xsl
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/
Transform">
<!-- Template to generate the document language -->
<xsl:template match="document">
<xsl:choose>
<xsl:when test="@xml:lang">
<xsl:copy-of select="@xml:lang"/>
</xsl:when>
<xsl:otherwise>
<title>*No* language found</title>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>
which I think the locationmap should be able to resolv, based on the
following snippet in plugins/o.a.f.plugin.internal.dispatcher/
locationmap.xml:
<match pattern="dataModel-xml-document-to-**.xsl">
<select type="exists">
<location
src="{properties:resources}stylesheets/xslt/xml/
document-to-{1}.xsl"
/>
<location
src="{lm:std-dataModel-xml-document-to-{1}.xsl}"
/>
</select>
</match>
With all this, and without changing the contract from what was
working earlier, I get the following error:
Internal Server Error
Message: null
Description: No details available.
Sender: org.apache.cocoon.servlet.CocoonServlet
Source: Cocoon Servlet
Request URI
index.html
cause
dispatcherError: 500 - Internal server error
The contract "language-variants" has thrown thrown an exception by
resolving raw data from "cocoon://index.languages.xml".
dispatcherErrorStack:
org.apache.excalibur.source.SourceException: Cannot get input
stream for cocoon://index.languages.xml
request-uri
/index.html;jsessionid=3anfa8koll7k8
Apache Cocoon 2.2.0-dev
From what I can see, it isn't able to resolve the stylesheet OR the
source document for some reason.
Sjur
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Hi Gav,
Den 15. sep. 2006 kl. 01.55 skrev Gav....:
>> I can see no traces of that message on the console, nor in any log
>> file.
>
> With the 'debug string-' I get :-
>
> cocoon://resolve.contract.html.language-variants; Line #0; Column #0;
> org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was
> made to
> insert a node where it is not permitted.
>
> And the SME no longer appears. If I remove 'debug string -' from the
> Contract then words SME appears as it should.
>
> Having now tested it further, it seems that where you put the words
> 'debug string -' makes a difference.
>
> You showed it as being :-
>
> <xsl:template match="/">
> debug string -
> <forrest:content>
>
> Which is when I get the error message, moving it to :-
>
> <xsl:template match="/">
> <forrest:content>
> debug string -
>
> cures this problem and my contract now works fine again, I get the
> words SME appear and the output is rendered as :
>
> <div id="languages">
> <!--+ |start language list +-->
> <div class="language-variants">
> SME
> </div>
>
> <!--+ |end language list +-->
> </div>
>
>
>
>>
>>> Unfortunatly it also makes this script fail, removing it cured it
>>> for me.
>>
>> I had/have no such problems.'
>>
>>> I also had a failure of
>>>
>>> <forrest:template xmlns:forrest="http://apache.org/forrest/
>>> templates/1.0"
>>>
>>> because they were separate, this may be a cut-n-paste thing on my
>>> part if
>>> the mail was wrapped.
>>
>> Probably since I didn't have any such problems with the code:-)
>
> Ok, but then I don't understand why it works for me then and not
> for you,
> The 'debug string -' is the ONLY thing I have changed to make it work
> For me, have you tried removing it or moving it as above.?
Sorry for not reading your first mail better - I attributed the error
message to the TEST string I had in the pelt.fv file, not to anything
in the contract itself. It was copied from the howto-structurer-
contracts.html page, in which the debug string occurs directly after
the <xsl:template> element (but there's no <forrest:content> element
in that example).
With the correction you made above, I get the same result as you - it
works!
Thanks so far, I will now continue with the next step. I'm certain I
will be back with more questions soon:-)
Sjur
RE: i18n/dispatcher: language selection contract
Posted by "Gav...." <br...@brightontown.com.au>.
Hi Sjur,
> -----Original Message-----
> From: Sjur Moshagen [mailto:sjurnm@mac.com]
> Sent: Thursday, 14 September 2006 11:10 PM
> To: dev@forrest.apache.org
> Subject: Re: i18n/dispatcher: language selection contract
>
> Den 14. sep. 2006 kl. 17.38 skrev Gav....:
>
> >> I have in my {$project}/resources/themes/pelt.fv the following
> >> snippet:
> >>
> >> <forrest:hook class="languages">TEST
> >> <forrest:contract name="language-variants" />
> >> </forrest:hook>
> >
> > Looks good, but I removed the word TEST.
>
> Ok. I already read the comment from Thorsten.
>
> >> for the hook. The first version of the contract, located in
> >> {$project}/resources/themes/common/html/language-variants.ft,
> >> contains the following:
> >
> > To be available for all themes this is the place to put it, but if
> > You are only using it in pelt theme and only declaring it in pelt.fv
> > Then putting it in /themes/pelt/html/language-variants.ft makes better
> > Sense, but does not make any difference to this working or not as
> > Common is fallback location, just thought I'd mention it.
>
> Thanks for informing me. I hope it would have common interest, if I
> ever get it to work:-)
Absolutely :)
>
> >> I would hve expected it to output "SME", but nothing shows up.
> >
> > It is looking good, two things to note here, having the 'debug
> > string -'
> > Gives an error message output to the console and is a good help.
>
> console should be the terminal window in which I'm running forrest,
> right?
Yep.
>
> I can see no traces of that message on the console, nor in any log file.
With the 'debug string-' I get :-
cocoon://resolve.contract.html.language-variants; Line #0; Column #0;
org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to
insert a node where it is not permitted.
And the SME no longer appears. If I remove 'debug string -' from the
Contract then words SME appears as it should.
Having now tested it further, it seems that where you put the words
'debug string -' makes a difference.
You showed it as being :-
<xsl:template match="/">
debug string -
<forrest:content>
Which is when I get the error message, moving it to :-
<xsl:template match="/">
<forrest:content>
debug string -
cures this problem and my contract now works fine again, I get the
words SME appear and the output is rendered as :
<div id="languages">
<!--+ |start language list +-->
<div class="language-variants">
SME
</div>
<!--+ |end language list +-->
</div>
>
> > Unfortunatly it also makes this script fail, removing it cured it
> > for me.
>
> I had/have no such problems.'
>
> > I also had a failure of
> >
> > <forrest:template xmlns:forrest="http://apache.org/forrest/
> > templates/1.0"
> >
> > because they were separate, this may be a cut-n-paste thing on my
> > part if
> > the mail was wrapped.
>
> Probably since I didn't have any such problems with the code:-)
Ok, but then I don't understand why it works for me then and not for you,
The 'debug string -' is the ONLY thing I have changed to make it work
For me, have you tried removing it or moving it as above.?
Thanks
Gavin
>
> Sjur
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.12.3/446 - Release Date: 9/12/2006
Re: i18n/dispatcher: language selection contract
Posted by Sjur Moshagen <sj...@mac.com>.
Den 14. sep. 2006 kl. 17.38 skrev Gav....:
>> I have in my {$project}/resources/themes/pelt.fv the following
>> snippet:
>>
>> <forrest:hook class="languages">TEST
>> <forrest:contract name="language-variants" />
>> </forrest:hook>
>
> Looks good, but I removed the word TEST.
Ok. I already read the comment from Thorsten.
>> for the hook. The first version of the contract, located in
>> {$project}/resources/themes/common/html/language-variants.ft,
>> contains the following:
>
> To be available for all themes this is the place to put it, but if
> You are only using it in pelt theme and only declaring it in pelt.fv
> Then putting it in /themes/pelt/html/language-variants.ft makes better
> Sense, but does not make any difference to this working or not as
> Common is fallback location, just thought I'd mention it.
Thanks for informing me. I hope it would have common interest, if I
ever get it to work:-)
>> I would hve expected it to output "SME", but nothing shows up.
>
> It is looking good, two things to note here, having the 'debug
> string -'
> Gives an error message output to the console and is a good help.
console should be the terminal window in which I'm running forrest,
right?
I can see no traces of that message on the console, nor in any log file.
> Unfortunatly it also makes this script fail, removing it cured it
> for me.
I had/have no such problems.
> I also had a failure of
>
> <forrest:template xmlns:forrest="http://apache.org/forrest/
> templates/1.0"
>
> because they were separate, this may be a cut-n-paste thing on my
> part if
> the mail was wrapped.
Probably since I didn't have any such problems with the code:-)
Sjur
RE: i18n/dispatcher: language selection contract
Posted by "Gav...." <br...@brightontown.com.au>.
Hi Sjur,
> -----Original Message-----
> From: Sjur Moshagen [mailto:sjurnm@mac.com]
> Sent: Thursday, 14 September 2006 8:26 PM
> To: dev@forrest.apache.org
> Subject: i18n/dispatcher: language selection contract
>
> Hello,
>
> I'm trying to make my first dispatcher contract. It turned out to be
> more problematic than I first thought, problems below the pseudocode.
>
> Here's what I want to do: I want to create a language selection list
> for a multilingual site. The language selection list should be
> dynamically generated for each document, since it isn't known which
> document have more than one language, and which languages are
> available for each document. The pseudocode goes like this:
>
> 1- get the request
> 2- get a list of all documents that matches the request, disregarding
> i18n infixes in the
> filenames (that is, a request for X.html should match all of:
> X.YY.xml
> X.ZZ.xml
> X.xml
> where YY, ZZ and <nothing> corresponds to available locales or
> the fallback file
> 3- examine the X.xml (fallback file) for an @xml:lang or @lang to
> determine the
> language of the document; if not found, use the site default (if
> available)
> 4- based on 2 and 3, create a list of all languages available
> 5- examine the document actually being returned by the request for
> @xml:lang or @lang,
> to be able to detect the currently viewed language (it could be
> different from
> the fallback document, since other i18n components can have
> picked a better
> choice based on browser settings)
> 6- return a list of available language variants, tagging the
> presently displayed
> language, and with each of the other languages as a link to that
> document (using,
> e.g. ?locale=YY or some other means to override browser settings)
>
> The list should be formatted with CSS to whatever is wanted. My
> present goal is to have a simple horisontal list across the page,
> between the menu on the left and the PDF icon on the right, just
> above the document title.
>
> Problem #1:
>
> I can't get the contract to do anything!
>
> I have in my {$project}/resources/themes/pelt.fv the following snippet:
>
> <forrest:hook class="languages">TEST
> <forrest:contract name="language-variants" />
> </forrest:hook>
Looks good, but I removed the word TEST.
>
> but it only returns an empty
>
> <div class="languages"/>
Yep, me too, but ....
>
> for the hook. The first version of the contract, located in
> {$project}/resources/themes/common/html/language-variants.ft,
> contains the following:
To be available for all themes this is the place to put it, but if
You are only using it in pelt theme and only declaring it in pelt.fv
Then putting it in /themes/pelt/html/language-variants.ft makes better
Sense, but does not make any difference to this working or not as
Common is fallback location, just thought I'd mention it.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <forrest:contract
> xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
> xmlns:forrest="http://apache.org/forrest/templates/1.0"
> name="language-variants">
>
> <description>
> <p>
> <strong>language-variants</strong> will output a list of
> available language for a given
> input document. The presently displayed language will be marked.
> Styling
> is done using CSS.
> </p>
> </description>
> <usage><![CDATA[<forrest:contract name="language-variants"
> dataURI="cocoon://#{$getRequest}.languages.xml"/>]]></usage>
> <forrest:template xmlns:forrest="http://apache.org/forrest/
> templates/1.0"
> name="language-variants" inputFormat="xsl">
> <xsl:stylesheet version="1.1"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> <xsl:template match="/">
> debug string -
> <forrest:content>
> <forrest:part>
> <xsl:comment>+ |start language list +</xsl:comment>
> <div class="language-variants">
> SME
> </div>
> <xsl:comment>+ |end language list +</xsl:comment>
> </forrest:part>
> </forrest:content>
> </xsl:template>
> </xsl:stylesheet>
> </forrest:template>
> </forrest:contract>
>
> I would hve expected it to output "SME", but nothing shows up.
It is looking good, two things to note here, having the 'debug string -'
Gives an error message output to the console and is a good help.
Unfortunatly it also makes this script fail, removing it cured it for me.
I also had a failure of
<forrest:template xmlns:forrest="http://apache.org/forrest/
templates/1.0"
because they were separate, this may be a cut-n-paste thing on my part if
the mail was wrapped.
HTH
Gav...
>
> I have tried to read and follow the instructions at:
>
> http://forrest.apache.org/docs_0_80/howto/howto-structurer-
> contracts.html
>
> and related pages linked to at the bottom.
>
> Any guidance would be greatly appreciated!
>
> Best regards,
> Sjur
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.12.3/446 - Release Date: 9/12/2006