Community
Participate
Working Groups
This is a duplicate of bug 242119 : When I create an HTML editor template extension using the following in the template.xml text: <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> <title>Insert title here</title> </head> <body> <div style="background-color:navy;width:100%;color:white"></div> </body> </html> The text "width:100&37;" gets translated when instantiated as "width:100!" instead of "width:100%" as expected. Furthermore, in the following template: <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <body> <div style="width:100%;font-size:36px;line-height:48px;background-color:navy;color:white">My Facelet Application</div> </body> </html> Not only does the width attribute "%" not get correctly translated, but a "!" is also inserted after the "My" in the "My Facelet Application" text.
Created attachment 167396 [details] Patch to fix Facelet HTML templates
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. Creating a XHTML page using the header and footer facelet template, the resulting page ignores the '%' character and also inject spurios, '!' character. This is annoying and will affect end-user experience. * Is there a work-around? If so, why do you believe the work-around is insufficient? Manuall edit the resulting file * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Manual testing. * Give a brief technical overview. Who has reviewed this fix? See comment 1 * What is the risk associated with this fix? None
I'm sorry ... its late in the day ... but I don't see what the fix is, here. The patch has changes that don't appear to be related to this bug. Fine, looks minor. But worst, I don't see how width:100&37; was changed. Can you spell it out for me? Sounds like a good fix for a very important problem, so I'm sure its fine. I'd like to understand the principle that leads to the solution. Is that principle documented? Is there some "best practice" to follow in the future? Or were these some sort of typo.
(In reply to comment #3) > I'm sorry ... its late in the day ... but I don't see what the fix is, here. > > The patch has changes that don't appear to be related to this bug. Fine, looks > minor. But worst, I don't see how width:100&37; was changed. Can you spell it > out for me? The patch moves the HTML text in the template.xml file to a properties file, where width is specified as "width:100%" . When used to create the XHTML file, the '%' is preserved and is not interpreted as a translation string. > > Sounds like a good fix for a very important problem, so I'm sure its fine. I'd > like to understand the principle that leads to the solution. Is that principle > documented? Is there some "best practice" to follow in the future? Or were > these some sort of typo. From :See https://bugs.eclipse.org/bugs/show_bug.cgi?id=242119#c2 : Looks to be in Platform code in TemplateReaderWriter. % gets unescaped into a %, but then the string gets translated starting at that %. Since the string key is not found in the bundle, you get the !! surrounding the "key" which is everything up until the newline (where your </div> ends).
k, thanks for spelling it out for me.
Patch released to RC1
