All, As an exercise, I decided to change my response content type from text/html to application/xhtml+xml as we are truly attempting to emit XHTML in all cases. I decided to see what Firefox would say if we did this.
I found that any template that uses the validator tool to generate Javascript form validation ended up creating code like this: function validateMyForm(form) { if (bCancel) return true; else var formValidationResult; formValidationResult = validateInteger(form) && validateRequired(form) && validateMaxLength(form) && validateMask(form) && validateIntRange(form); return (formValidationResult == 1); } I have "xhtml" set to true in my (admittedly) old-style configuration: <toolbox> <tool> <key>validator</key> <scope>request</scope> <class>org.apache.velocity.tools.struts.ValidatorTool</class> </tool> ... <xhtml>true</xhtml> </toolbox> ...but the code still emits '&&' as the operator with no escaping. It appears that a trivial fix for this is to call setCdata(true) on the validator before generating the dynamic javascript, and then the whole thing gets put into a CDATA section, so the XML parser does not complain. On the other hand, I really don't want to have to edit all of my templates just to add 'setCdata(true)' to fix this. I'd rather have ValidatorTool know that when in XHTML mode, the "&&" needs to be "&&" instead. Is the intent that XHTML content should always use CDATA sections (in which case I should just suck it up and updated my templates), or should it be considered a bug that XHTML doesn't either automatically trigger the use of CDATA sections OR the generation of "&&" instead of "&&"? Thanks, -chris
signature.asc
Description: OpenPGP digital signature