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
"&amp;&amp;" 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 "&amp;&amp;" instead of "&&"?

Thanks,
-chris

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to