Thanks Max, Bug reported created: https://issues.apache.org/jira/browse/TRINIDAD-1811
I'm not sure about the priority though, I'll leave it to the project team to decide what's appropriate. Best regards, Stéphane ======================================== Message du : 18/05/2010 De : "Max Starets " <[email protected]> A : "MyFaces Discussion" <[email protected]> Copie à : Sujet : Re: [TRINIDAD] Trinidad 1.2.13 + MyFaces 1.2.8 + Tomahawk 1.2.9 + Facelets 1.1.14: tabs in facelets ending in the page output in their escaped form Stéphane, Thanks for verifying the difference in behavior. You are right - Mojarra and MyFaces allow the tab character to remain unescaped. Mojarra in particular allows 4 control characters to appear in the output: LF, TAB, CR, FF Trinidad allows only LF and CR. Given that XML spec explicitly allows the tab character to appear in the document (http://www.w3.org/TR/REC-xml/ - Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646), I think we should modify Trinidad to allow TAB characters to remain unescaped. Could you file a Trinidad JIRA for this issue? Although the fix would be trivial, we want to make sure that there are no objections to the change. Regards, Max Stéphane Rondinaud wrote: > Hello Max, hello all, > > Attached is the tests Max requested. All tests runs with an "mvn > integration-test". > > The archive has 3 directories: > - JSF RI + Facelets > - Myfaces + Facelets > - the same test with Trinidad 1.2.13 as before failing on the > escaping integration test > > The RI/Myfaces + Facelets tests exhibit what I'd consider normal > behaviour (i.e. tabs getting through as tabs, unescaped), the trinidad > still escaping them as " ". > > Feel free to ask any additional tests you see fit, > > Best regards, > > Stéphane > > > > > Le 17 mai 10 à 21:49, Max Starets a écrit : > >> >> Stéphane, >> >> I believe Trinidad was always supposed to escape tab characters. >> >> Could you try your sample with MyFaces+Facelets and JSF RI+Facelets >> without Trinidad? >> >> Thanks, >> Max >> >> Stéphane Rondinaud wrote: >>> Hello Max, >>> >>> The trouble when using a handful of framework is that when something >>> breaks, the question is always to "which one is broken?". If I >>> posted here, it's because Trinidad was the only framework that >>> changed when the problem happened. >>> >>> You'll find attached a lightly modified version of the test case. >>> It's a maven project again, and the integration test is illustrating >>> the problem. It expects a trinidadRelease parameter as follow: >>> >>> mvn -DtrinidadRelease=12 integration-test >>> >>> => this results in no problem on the integration test >>> >>> mvn -DtrinidadRelease=13 integration-test >>> >>> => this results in a failure of the test checking the presence of >>> " " in the output page >>> >>> Now it could be that up to and excluding release 13, Trinidad was >>> incorrectly dealing with the tabs by passing them as is to the >>> output page. Thus we'd have built our application on a false >>> premise, thus the current problem? >>> >>> I suspect a little regression though: the revision I indicated in my >>> previous post was modifying a serious bit of code in files named >>> HtmlEscapes/XmlEscapes or something similar. I've got had time yet >>> to delve into Trinidad code but the fact that between release 12 and >>> 13 the behaviour changed strikes me as a more than probable cause of >>> the problem. >>> >>> Best regards, >>> >>> Stéphane Rondinaud >>> >>> Le 17 mai 10 à 17:12, Max Starets a écrit : >>> >>>> >>>> Hi Stéphane, >>>> >>>> I was able to reproduce your problem, but I believe this is more of >>>> a Facelets issue. >>>> The Facelets engine is using ResponseWriter.writeText() to render >>>> all text between the tags >>>> including the white space. Since the tab character is not a valid >>>> HTML/XML character, Trinidad >>>> is escaping it, as I believe it should given that it is being asked >>>> to write text. >>>> >>>> Note that you would get ResponseWriter.write() being called if you >>>> had a JSPX document. >>>> I think your only choice is to replace the tab characters with >>>> space characters. >>>> >>>> Is it only me, or do you guys think that Facelets/JSF2 should be >>>> exposing SKIP_WHITE_SPACE context >>>> parameter just like it does with SKIP_COMMENTS ? >>>> >>>> Max >>>> >>>> Stéphane Rondinaud wrote: >>>>> Hello all, >>>>> >>>>> I needed to update to 1.2.13 to solve a problem with search engine >>>>> bots generation NPEs, and just after the switch, I realized that >>>>> some tabs present in the different facelets pages were getting >>>>> through to the output page escaped as " ", ruining my attempt >>>>> at having conforming webpages - the tabs being in the >>>>> , the validation fails... >>>>> >>>>> I traced back the problem to commit 886958 related to bug >>>>> TRINIDAD-1655. What's bothering me is that I seem to be the only >>>>> one to have this problem as I couldn't find any post on the >>>>> mailing list about such a problem. >>>>> >>>>> You'll find attached a minimal maven project illustrating the >>>>> problem. Launching it by "mvn jetty:run" and browsing to >>>>> http://localhost:8080/TrinidadTest/ will return a page with some >>>>> " " in place of regular tabs. >>>>> >>>>> One last thing: I tried to use a Selenium test to track the >>>>> problem but it seems that the "getHtmlSource()" method replaces >>>>> automatically the with regular tabs, thus rendering the test >>>>> useless. >>>>> >>>>> Please feel free to request anything that could help finding the >>>>> cause of the issue, >>>>> >>>>> Best regards, >>>>> >>>>> Stéphane Rondinaud >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >
