RE: i18nTransformer problems with static pages
Sry for the delay. Shall I commit the StripNameSpaceTransformer to trunk/core/cocoon-pipeline/cocoon-pipeline-components/./transformation , or is there a more preferable location? Should I also add it to the branch? Ard 1) The lightweight StripNameSpaceTransformer ... Add this to trunk/branch or not? If no objections, I'll add my version of the StripNameSpaceTransformer to the trunk/branch on short notice +1 2) The XHTML serializer: Make it by default strip the list of namespaces we know people don't want to sent to the browser. -1 No, please don't. If you have a browser that does not understand XHTML (like IE) don't feed it with XHTML! It's as simple like that. If it understands XHTML it also must be able to handle namespace declarations and additional XML-specific attributes like xml:space or xml:lang. Do you want to suppress them as well? Such a behaviour might be valid for a HTMLSerializer though. But actually I don't care for that one when we have StripNameSpaceTransformer. About serializers: Does anybody know why we have a serialization part in cocoon core and one in a serializers block? Is it preferred to use serializers from the serializers block? Normally, I am using org.apache.cocoon.serialization.HTMLSerializer and configure doctype-public. Those from core are Xalan's serializers at the end. Those from serializers block are own implementations from Cocoon once made by Pier. As Cocoon should not write serializer IMO I prefer the core ones. I agree on this one. A better integration with Xalan community to get our wishes applied to those serializers might be desirable (one issue was the closing of tags, which must not be closed or consist only of a start tag in HTML IIRC). This would make our own implementations superfluous. Jörg
Re: i18nTransformer problems with static pages
On 1/3/07, Ard Schrijvers [EMAIL PROTECTED] wrote: Should I also add it to the branch? +1 -Bertrand
Re: i18nTransformer problems with static pages
Ard Schrijvers skrev: Sry for the delay. Shall I commit the StripNameSpaceTransformer to trunk/core/cocoon-pipeline/cocoon-pipeline-components/./transformation , or is there a more preferable location? Should I also add it to the branch? Seem like a reasonable place as long as the cocoon-pipline-components give have all the dependencies you need, if not, put it in the cocoon-sitemap-components or cocoon-core. /Daniel
RE: i18nTransformer problems with static pages
Ard Schrijvers skrev: Sry for the delay. Shall I commit the StripNameSpaceTransformer to trunk/core/cocoon-pipeline/cocoon-pipeline-components/./tr ansformation , or is there a more preferable location? Should I also add it to the branch? Seem like a reasonable place as long as the cocoon-pipline-components give have all the dependencies you need, Yes, it has. I just committed it to the trunk and branche. Not sure wether it is common practice to create a jira issue for it when committing something new and resolve it? Should I do this normally? Or still do this? Ard if not, put it in the cocoon-sitemap-components or cocoon-core. /Daniel
Re: i18nTransformer problems with static pages
On 1/3/07, Ard Schrijvers [EMAIL PROTECTED] wrote: ...Not sure wether it is common practice to create a jira issue for it when committing something new and resolve it?... I don't think it's common practice here but IMHO it's a Good Thing. -Bertrand
RE: i18nTransformer problems with static pages
On 1/3/07, Ard Schrijvers [EMAIL PROTECTED] wrote: ...Not sure wether it is common practice to create a jira issue for it when committing something new and resolve it?... I don't think it's common practice here but IMHO it's a Good Thing. Locally we added this svn 'pre-commit' hook to prohibit a commit that did not contain a reference to a jira issue. In jira, via an issue, you can then find the commits that below to it. Although it is sometimes a little annoying, it forces everybody here to work always according jira issues and commits can always be easily traced from a certain jira issue. Not sure if it would make people happy in an open source community :-) Ard -Bertrand
Re: i18nTransformer problems with static pages
On 03.01.2007 17:47, Ard Schrijvers wrote: Locally we added this svn 'pre-commit' hook to prohibit a commit that did not contain a reference to a jira issue. In jira, via an issue, you can then find the commits that below to it. Although it is sometimes a little annoying, it forces everybody here to work always according jira issues and commits can always be easily traced from a certain jira issue. Not sure if it would make people happy in an open source community :-) It's at least not that uncommon. The geronimo community worked after an even stricter model called Review Then Commit (RTC, [1]) until recently. They created a Jira issue for *every* change and it needed at least 3 positive votes until it got committed. I agree adding a Jira issue for important svn commits or such enhancements is a Good Thing, but I would not enforce it. Regards Jörg [1] http://marc.theaimsgroup.com/?l=geronimo-devm=113743624112026w=4
RE: i18nTransformer problems with static pages
1) The lightweight StripNameSpaceTransformer ... Add this to trunk/branch or not? If no objections, I'll add my version of the StripNameSpaceTransformer to the trunk/branch on short notice +1 2) The XHTML serializer: Make it by default strip the list of namespaces we know people don't want to sent to the browser. -1 No, please don't. If you have a browser that does not understand XHTML (like IE) don't feed it with XHTML! It's as simple like that. If it understands XHTML it also must be able to handle namespace declarations and additional XML-specific attributes like xml:space or xml:lang. Do you want to suppress them as well? Such a behaviour might be valid for a HTMLSerializer though. But actually I don't care for that one when we have StripNameSpaceTransformer. About serializers: Does anybody know why we have a serialization part in cocoon core and one in a serializers block? Is it preferred to use serializers from the serializers block? Normally, I am using org.apache.cocoon.serialization.HTMLSerializer and configure doctype-public. Those from core are Xalan's serializers at the end. Those from serializers block are own implementations from Cocoon once made by Pier. As Cocoon should not write serializer IMO I prefer the core ones. I agree on this one. A better integration with Xalan community to get our wishes applied to those serializers might be desirable (one issue was the closing of tags, which must not be closed or consist only of a start tag in HTML IIRC). This would make our own implementations superfluous. Jörg
RE: i18nTransformer problems with static pages
Recapitulating this thread: 1) The lightweight StripNameSpaceTransformer is an option to strip intermediate namespaces you want to get rid of (like after sql transformer, I would like to get rid of them as fast as possible). Add this to trunk/branch or not? 2) The XHTML serializer: Make it by default strip the list of namespaces we know people don't want to sent to the browser. Configurable: added namespaces to be stripped. About serializers: Does anybody know why we have a serialization part in cocoon core and one in a serializers block? Is it preferred to use serializers from the serializers block? Normally, I am using org.apache.cocoon.serialization.HTMLSerializer and configure doctype-public. Ard Mark Lundquist wrote: Is there ever a need to retain namespace declarations for namespaces that are not actually used in the result document, i.e. for which there is no element with that namespace? I think the idea is to just delete extraneous namespace declarations, not to delete them all... Yep, the problem with this approach is that you manage to know if a namespace declaration has been used only when you reach the end of the document (after checking that no element used it), while the declaration is quite commonly on the root element. Buffering all the SAX event for each html page served by cocoon would be a problem :) What i was proposing would be simply to enable it by default (already too many options in cocoon, and if a page containing a i18n namespace declaration is not visualized by IE, by default cocoon should not send it), but limit it's influence on a set of namespaces (all namespaces http://cocoon.apache.org for example) and eventually have this set configurable by the user so that there will be no need in the future for remove-that-certain-unwanted-ns.xsl files :D Simone
Re: i18nTransformer problems with static pages
On Dec 7, 2006, at 2:51 AM, Ard Schrijvers wrote: 1) The lightweight StripNameSpaceTransformer is an option to strip intermediate namespaces you want to get rid of (like after sql transformer, I would like to get rid of them as fast as possible). Add this to trunk/branch or not? +1 2) The XHTML serializer: Make it by default strip the list of namespaces we know people don't want to sent to the browser. Configurable: added namespaces to be stripped. -1. IMO (a) the serializers are not the place to do anything w/ namespaces, and (b) in particular w/ XHTML you have no idea what namespaces I want or don't want sent to the browser, (c) you said by default which implies some way of overriding the default, i.e. another configuration detail to document, and (d) if we're adding a transformer to do this already (see above), then it's kind of moot :-) About serializers: Does anybody know why we have a serialization part in cocoon core and one in a serializers block? Is it preferred to use serializers from the serializers block? Good question, I'd like to know as well... Cheers, —ml—
Re: i18nTransformer problems with static pages
On 07.12.2006 11:51, Ard Schrijvers wrote: 1) The lightweight StripNameSpaceTransformer ... Add this to trunk/branch or not? +1 2) The XHTML serializer: Make it by default strip the list of namespaces we know people don't want to sent to the browser. -1 No, please don't. If you have a browser that does not understand XHTML (like IE) don't feed it with XHTML! It's as simple like that. If it understands XHTML it also must be able to handle namespace declarations and additional XML-specific attributes like xml:space or xml:lang. Do you want to suppress them as well? Such a behaviour might be valid for a HTMLSerializer though. But actually I don't care for that one when we have StripNameSpaceTransformer. About serializers: Does anybody know why we have a serialization part in cocoon core and one in a serializers block? Is it preferred to use serializers from the serializers block? Normally, I am using org.apache.cocoon.serialization.HTMLSerializer and configure doctype-public. Those from core are Xalan's serializers at the end. Those from serializers block are own implementations from Cocoon once made by Pier. As Cocoon should not write serializer IMO I prefer the core ones. A better integration with Xalan community to get our wishes applied to those serializers might be desirable (one issue was the closing of tags, which must not be closed or consist only of a start tag in HTML IIRC). This would make our own implementations superfluous. Jörg
Re: i18nTransformer problems with static pages
I'm using IE7. But this is much complicated problem, i think. When I use this xsl stylesheet to remowe attributes with namespace prefixes, it works. when I use map:read instead of map:generate it works too(with xmlns:i18x attribute). Maybe it is problem with serialization? (Does IE work with xhtml mime?) Greetings Piotr -- View this message in context: http://www.nabble.com/i18nTransformer-problems-with-static-pages-tf2750404.html#a7715509 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
RE: i18nTransformer problems with static pages
You should add an extra stylesheet that removes superfluous namespace
attributes. This is what I've done:
I used to use this strategy as well, though recently I replaced this xsl
transformer with a custom StripNameSpacesTransformer (about just 10 lines),
which outperforms the slow xsl transformation a factor 30 for small xml docs,
over hundreds of times for bigger xml docs. I am not sure if it is already
available in cocoon in some transformer.
If somebody is interested in the code, I can attach it,
Regards Ard
xsl:template match=*
!-- remove element prefix (if any) --
xsl:element name={local-name()}
!-- process attributes --
xsl:for-each select=@*
!-- remove attribute prefix (if any) --
xsl:attribute name={local-name()}
xsl:value-of select=./
/xsl:attribute
/xsl:for-each
xsl:apply-templates/
/xsl:element
/xsl:template
Add a generic catchall template or you end up with nothing:
!-- = --
!-- generic catchall template --
!-- = --
xsl:template match=text()
xsl:copy
xsl:apply-templates select=text()/
/xsl:copy
/xsl:template
HTH
Bye, Helma
Re: i18nTransformer problems with static pages
Ard Schrijvers wrote:
You should add an extra stylesheet that removes superfluous namespace
attributes. This is what I've done:
I used to use this strategy as well, though recently I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30 for small xml docs, over hundreds of times for bigger xml docs. I am not sure if it is already available in cocoon in some transformer.
If somebody is interested in the code, I can attach it,
if you mean adding to trunk/branch21, +1
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: i18nTransformer problems with static pages
On 12/5/06, Ard Schrijvers [EMAIL PROTECTED] wrote: ...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! -Bertrand
RE: i18nTransformer problems with static pages
...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! I thought it was too trivial :-) Will add it to trunk/branch Ard -Bertrand
Re: i18nTransformer problems with static pages
Ard Schrijvers said the following on 5/12/06 12:40: ...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! I thought it was too trivial :-) Will add it to trunk/branch As a friend of mine says: it's always amazing to see how easy it is to make Cocoon do very difficult things when it is so hard to make it do the trivial things, so by all means submit your transformer and I'm your first customer. ;-) Bye, Helma
Re: i18nTransformer problems with static pages
On 12/5/06, Ard Schrijvers [EMAIL PROTECTED] wrote: You should add an extra stylesheet that removes superfluous namespace attributes. This is what I've done: I used to use this strategy as well, though recently I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30 for small xml docs, over hundreds of times for bigger xml docs. I am not sure if it is already available in cocoon in some transformer. If somebody is interested in the code, I can attach it, Instead of requiring that an extra transformer be added to the pipeline would it make sense to add this capability as a configuration option on the HTML/XHTML serializers? -- Peter Hunsberger
Re: i18nTransformer problems with static pages
On Dec 5, 2006, at 7:35 AM, Peter Hunsberger wrote: Instead of requiring that an extra transformer be added to the pipeline would it make sense to add this capability as a configuration option on the HTML/XHTML serializers? +1 IIRC this very thing was proposed some time ago and either rejected for some reason, or just didn't happen. I think it's a great idea, but it'd be worth a troll through the archives to see if there isn't some compelling reason not to. —ml—
Re: i18nTransformer problems with static pages
Peter Hunsberger wrote: Instead of requiring that an extra transformer be added to the pipeline would it make sense to add this capability as a configuration option on the HTML/XHTML serializers? Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. - Obviously not for the XML output (note that xhtml and xml serializer are the same class) Simone
Re: i18nTransformer problems with static pages
On 12/5/06, Simone Gianni [EMAIL PROTECTED] wrote: Peter Hunsberger wrote: Instead of requiring that an extra transformer be added to the pipeline would it make sense to add this capability as a configuration option on the HTML/XHTML serializers? Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. Umm, that's why it would be an _option_... (obviously not the default). - Obviously not for the XML output (note that xhtml and xml serializer are the same class) -- Peter Hunsberger
Re: i18nTransformer problems with static pages
On Dec 5, 2006, at 8:38 AM, Simone Gianni wrote: Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. - Obviously not for the XML output (note that xhtml and xml serializer are the same class) Is there ever a need to retain namespace declarations for namespaces that are not actually used in the result document, i.e. for which there is no element with that namespace? I think the idea is to just delete extraneous namespace declarations, not to delete them all... —ml—
Re: i18nTransformer problems with static pages
On 12/5/06, Mark Lundquist [EMAIL PROTECTED] wrote: On Dec 5, 2006, at 8:38 AM, Simone Gianni wrote: Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. - Obviously not for the XML output (note that xhtml and xml serializer are the same class) Is there ever a need to retain namespace declarations for namespaces that are not actually used in the result document, i.e. for which there is no element with that namespace? I think the idea is to just delete extraneous namespace declarations, not to delete them all... I could see both options. There are some cases where I really don't need any namespaced elements at all on my output (eg, stuff I'm manipulating for AJAX code). We strip them out with XSLT at the moment, but... -- Peter Hunsberger
Re: i18nTransformer problems with static pages
Mark Lundquist wrote: Is there ever a need to retain namespace declarations for namespaces that are not actually used in the result document, i.e. for which there is no element with that namespace? I think the idea is to just delete extraneous namespace declarations, not to delete them all... Yep, the problem with this approach is that you manage to know if a namespace declaration has been used only when you reach the end of the document (after checking that no element used it), while the declaration is quite commonly on the root element. Buffering all the SAX event for each html page served by cocoon would be a problem :) What i was proposing would be simply to enable it by default (already too many options in cocoon, and if a page containing a i18n namespace declaration is not visualized by IE, by default cocoon should not send it), but limit it's influence on a set of namespaces (all namespaces http://cocoon.apache.org for example) and eventually have this set configurable by the user so that there will be no need in the future for remove-that-certain-unwanted-ns.xsl files :D Simone
Re: i18nTransformer problems with static pages
On Dec 5, 2006, at 9:29 AM, Simone Gianni wrote: Yep, the problem with this approach is that you manage to know if a namespace declaration has been used only when you reach the end of the document (after checking that no element used it) Yeah, it takes two passes. Better to declare up-front which namespaces to preserve... What i was proposing would be simply to enable it by default (already too many options in cocoon, and if a page containing a i18n namespace declaration is not visualized by IE, by default cocoon should not send it), but limit it's influence on a set of namespaces (all namespaces http://cocoon.apache.org for example) and eventually have this set configurable by the user so that there will be no need in the future for remove-that-certain-unwanted-ns.xsl files :D I'm not keen on magic or specialness based on either (a) IE misbehavior, or (b) cocoon URIs. Anyway, like you have said, this thing is starting to have too many options for common feature of XML/HTML serializers... I'm now leaning back toward the idea of a transformer. The objection that it's onerous to include this transformer in every pipeline is weak, because (a) it doesn't have to be in every pipeline, only in final presentation pipelines, and (b) you'd naturally factor that and the serializer into a map:resource anyway. How about a NamspaceTransformer, configured with namespaces null-namespace/ namespace prefix=prefixURI/namespace . . . namespaces Where: 1) If null-namespace is present, then the null NS is the default NS 2) Otherwise, the NS with @default=true is the default NS (more than 1 such = error, or 0 if we have null-namespace/ 3) @prefix is optional; if not set, then use the first prefix found for the NS 4) The transformer writes all the namespace declarations into the root element, deletes them from any descendant elements 5) If a namespace is found that is not in the configured namespaces, throw an error How does that sound? —ml—
Re: i18nTransformer problems with static pages
Ard Schrijvers wrote: ...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! I thought it was too trivial :-) There is also less trivial CleanupTransformer [1]. It is overkill though for simple namespace stripping. Vadim [1] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/CleanupTransformer.html
Re: i18nTransformer problems with static pages
Sorry Piotr, which version of IE are you using? I can see pages containing xmlns declarations with all IE versions I have here in my office. Quite commonly the blank page in IE is caused by a head like this : html head title/ /head IE is intelligent enought to think that the full page is a title. This happens at least in versions 5.x of IE, and generating such a head is pretty simple : xsl:template head titlexsl:value-of select=somtingwrOnghere//title /head Are you sure the problem is the attribute? Cause if not we are talking about a nice feature but absolutely non blocking and by far not a priority. Simone falcorn wrote: I removed dtd declaration and xml:space attribute has gone; But there is declaration of xmlns:i18n at html tag. And IE dosen't like this attribute. I get blank page. In FF everything is correct, I only get some warrnings from Tidy that there is not standard attribute at html tag: xmlns:i18n greetings Piotr Idzikowski
RE: i18nTransformer problems with static pages
Hi Piotr,
are you sure it comes from the i18n transformer? What happens if you comment
out the i18n transformer and look at the result of the pipeline?
Kind regards,
Jeroen Reijn
Hippo
-Original Message-
From: falcorn [mailto:[EMAIL PROTECTED]
Posted At: Monday, December 04, 2006 11:44 AM
Posted To: Cocoon Dev List
Conversation: i18nTransformer problems with static pages
Subject: i18nTransformer problems with static pages
Hi. I have something like this at sitemap.
map:transformer name=i18n logger=sitemap.transformer.i18n
src=org.apache.cocoon.transformation.I18nTransformer
catalogues default=messages
catalogue id=messages name=messages
location=translations/
/catalogues
cache-at-startupfalse/cache-at-startup
/map:transformer
and next
map:match pattern=index.html
map:generate src=static/index.html/
map:transform type=i18n
map:parameter name=locale value={../locale}/
/map:transform
map:serialize type=html/
/map:match
and in index.html:
?xml version='1.0'?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:i18n=http://apache.org/cocoon/i18n/2.1; i18n:attr=language
language=language
head
titleRechnungs Archiv/title
meta content=no-cache http-equiv=pragma /
meta content=0 http-equiv=expires /
script type=text/javascript src=prototype.js /
script type=text/javascript src=window.js /
script type=text/javascript src=popup_window.js/script
script type=text/javascript src=js.js/script
script type=text/javascript src=invoicesSearch.js/script
script type=text/javascript src=invoicesPrinting.js/script
style type=text/css media=all@import invoices.css; @import
alert.css;/style
/head
body onload=getContents('portal');
div id=header
header_logo_como.jpg
span
onclick=getContents('portal');i18n:textPortal.portal/i18n:text/span
span
onclick=getContents('/invoices/logout');i18n:textPortal.logout/i18n:text/span
/div
div id=titleArchiv/div
div id=contents
/div
/body
/html
It works, but not at all. There is strange output:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:i18n=http://apache.org/cocoon/i18n/2.1; language=language
head
titleRechnungs Archiv/title
meta content=no-cache http-equiv=pragma/
meta content=0 http-equiv=expires/
script type=text/javascript src=prototype.js xml:space=preserve/
script type=text/javascript src=window.js xml:space=preserve/
script type=text/javascript src=popup_window.js
xml:space=preserve/
script type=text/javascript src=js.js xml:space=preserve/
script type=text/javascript src=invoicesSearch.js
xml:space=preserve/
script type=text/javascript src=invoicesPrinting.js
xml:space=preserve/
style type=text/css media=all xml:space=preserve@import
invoices.css; @import alert.css;/style
/head
body onload=getContents('portal');
div id=header
header_logo_como.jpg
span onclick=getContents('portal');Portal/span
span onclick=getContents('/invoices/logout');Logout/span
/div
div id=titleArchiv/div
div id=contents
/div
/body
/html
There are strange xml:space tag.
And in MsWord this page is not visible.
What i've done wrong?
Could You help me?
Greetings Piotr
--
View this message in context:
http://www.nabble.com/i18nTransformer-problems-with-static-pages-tf2750404.html#a7673784
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
RE: i18nTransformer problems with static pages
I've commented this i18n transform tag. And is the same. So it isn't i18nTransformer problem. But where is a problem? Can it be because i'm using saxon as default xslt transformer? -- View this message in context: http://www.nabble.com/i18nTransformer-problems-with-static-pages-tf2750404.html#a7674721 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: i18nTransformer problems with static pages
Piotr, this also happens when using Xalan. It seems that by removing the dtd declaration the xml:space tags are removed. Kind regards, Jeroen Reijn falcorn wrote: I've commented this i18n transform tag. And is the same. So it isn't i18nTransformer problem. But where is a problem? Can it be because i'm using saxon as default xslt transformer?
Re: i18nTransformer problems with static pages
There are strange xml:space tag. And in MsWord this page is not visible. What exactly do you mean with this page is not visible in MSWord. What happens if you open the page in your browser? What i've done wrong? Could You help me? Greetings Piotr Reijn
Re: i18nTransformer problems with static pages
What exactly do you mean with this page is not visible in MSWord. What happens if you open the page in your browser? Sorry. It is my fault. Now it is correct. I was thinking about IExplorer. Greetings -- View this message in context: http://www.nabble.com/i18nTransformer-problems-with-static-pages-tf2750404.html#a7675897 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: i18nTransformer problems with static pages
I removed dtd declaration and xml:space attribute has gone; But there is declaration of xmlns:i18n at html tag. And IE dosen't like this attribute. I get blank page. In FF everything is correct, I only get some warrnings from Tidy that there is not standard attribute at html tag: xmlns:i18n greetings Piotr Idzikowski -- View this message in context: http://www.nabble.com/i18nTransformer-problems-with-static-pages-tf2750404.html#a7675999 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: i18nTransformer problems with static pages
falcorn said the following on 4/12/06 13:47:
I removed dtd declaration and xml:space attribute has gone;
But there is declaration of xmlns:i18n at html tag.
And IE dosen't like this attribute. I get blank page.
In FF everything is correct, I only get some warrnings from Tidy that there
is not standard attribute at html tag: xmlns:i18n
You should add an extra stylesheet that removes superfluous namespace
attributes. This is what I've done:
xsl:template match=*
!-- remove element prefix (if any) --
xsl:element name={local-name()}
!-- process attributes --
xsl:for-each select=@*
!-- remove attribute prefix (if any) --
xsl:attribute name={local-name()}
xsl:value-of select=./
/xsl:attribute
/xsl:for-each
xsl:apply-templates/
/xsl:element
/xsl:template
Add a generic catchall template or you end up with nothing:
!-- = --
!-- generic catchall template --
!-- = --
xsl:template match=text()
xsl:copy
xsl:apply-templates select=text()/
/xsl:copy
/xsl:template
HTH
Bye, Helma
