<sitemesh> <page-parsers> <parser content-type="text/html" class="com.opensymphony.module.sitemesh.parser.FastPageParser" /> <parser content-type="text/html;charset=ISO-8859-1" class="com.opensymphony.module.sitemesh.parser.FastPageParser" /> <parser content-type="text/html;charset=UTF-8" class="com.opensymphony.module.sitemesh.parser.FastPageParser" /> </page-parsers> <decorator-mappers> <mapper class="org.codehaus.groovy.grails.web.sitemesh.GrailsLayoutDecoratorMapper" /> </decorator-mappers> </sitemesh>
How many of you Grails developers have ever had to look in there? Cool isn't it that Grails shields you from this stuff - one of the many, many reasons why I love this framework.
Unfortunately, FastPageParser is actually deprecated and has bugs when using the <content tag="x"> constructs - HTML comments are output as raw text and <script> tags loose their <. Migrating to Site Mesh 2.4.1 (or .2 now with the GAE) fixes the <script> problem, but not the HTML problem.The partial solution (as emailed to me by one James) is to replace it with the HTTPPageParser - this is faster (by about twice) and is the recommended replacement for FastPageParser.
The only problem is that it has an outstanding bug - if you include an "<" anywhere in an HTML element (e.g. in the value) then the rendering goes haywire. It is a known fault in Site Mesh but no-one bothered to create a test case for Joe or investigate precisely where the problem is. Content tags are pretty important to anyone laying out their content in any kind of sophisticated manner (as is extractProperty, which isn't actually surfaced in Grails for some weird reason), so I gave Joe the test case and narrowed it down to the Lex rules. Unfortunately, I am not a Lex guru, so I had to leave it there.
I'll be putting up a screen cast of this stuff at some point in the near future. I'll link when its available.