Shale validator wish list

[Jeff Tsay <jc...@aim.com>]

Hi,

I've been trying to integrate the Shale validator stuff with xulfaces. 
I've come across the following problems, some of which I have fixes for. 
Your input would be appreciated, hope I can check some of the stuff in.

1) As I mentioned in the shale user mailing list, when the validator 
script gets rendered, it outputs raw Javascript inside the <script> 
tags. The Javascript includes characters like & which need to be escaped 
or in a CDATA section in XML. For XUL or XHTML, this is a problem. I 
guess that XHTML parsers are more lenient about this so that's why the 
problem never showed up? Anyway the fix, which was also suggested by 
Gary VanMatre, was to enclose the script contents in an XML CDATA 
section. So in 
src/main/java/org/apache/shale/validator/faces/ValidatorScript.java I have:

 private void writeScriptStart(ResponseWriter writer) throws IOException {
      writer.startElement("script", this);
      writer.writeAttribute("type", "text/javascript", null);
      writer.writeAttribute("language", "Javascript1.1", null);
      writer.write("\n");
     
      // jtsay added
      // Enclose XML in CDATA so special characters can be used without 
escaping.
      if (!"text/html".equals(writer.getContentType())) {
          writer.write("<![CDATA[\n");
      }
    }

and

private void writeScriptEnd(ResponseWriter writer) throws IOException {
     // jtsay added
      if (!"text/html".equals(writer.getContentType())) {
          writer.write("\n]]>\n");
      }
         
      writer.write("\n");
      writer.endElement("script");
   }

This assumes if we are not rendering text/html, we must be rendering 
some sort of XML. Sound reasonable?


2) It seems strange the way that configuration rules are loaded. If the 
default configuration file is not found, the validator lifecycle 
listener will add the default configuration file to the end of a url 
list. However, since the list is processed in forward order, that means 
if you leave out the default configuration file, any settings you have 
in your own file will be overwritten by the default. That means you need 
to explicitly put the default configuration file in your 
org.apache.shale.validator.VALIDATOR_RULES list before your own files. 
Since I think it makes more sense to have your specified configuration 
files override the default settings, I propose the following change in 
ValidatorLifeCycleListener:


 private ValidatorResources validatorResources(ServletContext context)
      throws IOException, SAXException {

        // Process the explicitly configured resources (if any)
       // jtsay
        // Since we want to add to the beginning later, use a linked list
        // ArrayList urls = new ArrayList()
         LinkedList urls = new LinkedList();


         ...


       // Process the default configuration resources (if not already 
loaded)
        if (!didDefault) {
            try {
                url = context.getResource(Globals.DEFAULT_VALIDATOR_RULES);
            } catch (MalformedURLException e) {
                throw new IllegalArgumentException("MalformedURLException:"
                        + " The URL '" + Globals.DEFAULT_VALIDATOR_RULES
                        + "' specified as a validator rules resource is 
malformed.");
            }
            if (url == null) {
                url = 
ValidatorLifecycleListener.class.getResource(Globals.DEFAULT_VALIDATOR_RULES);
            }
            if (url == null) {
                throw new 
IllegalArgumentException(Globals.DEFAULT_VALIDATOR_RULES);
            }
         
           // jtsay
            // Add to beginning of list so that explicit resources override
            // default, not the other way around.
            urls.addFirst(url);
        }

3) Finally, I'd like to see the ability to override the validation error 
handler. Currently, with the default validatorUtilities.js, whenever a 
validation error occurs, an alert is displayed. To me that is a bit 
unpolished; I'd rather see some message below the input field that has 
an error. Although it's easy enough to replace validatorUtilities.js, 
jcv_handleError() simply doesn't get enough information in its arguments 
to do much with the DOM tree, unless the ID's of the elements to replace 
are hardcoded. It would be good also to let the user supply his own 
error handling script in the JSF tags, instead of messing with replacing 
validatorUtilities (which would be apply across the entire web app 
anyway). Any ideas on how to do this? Is anyone else interested in 
getting rid of alert()?

Thanks,

Jeff

Re: Shale validator wish list

[Rahul Akolkar <ra...@gmail.com>]

Could you please open separate tickets for each item, along with any
patches you'd like to propose, in the Shale JIRA [1] (Validator
component) ?

Unless someone looks at this immediately, that will better ensure that
these stay on some roadmap.

-Rahul

[1] https://issues.apache.org/struts/browse/SHALE


On 4/16/08, Jeff Tsay <jc...@aim.com> wrote:
> Hi,
>
>  I've been trying to integrate the Shale validator stuff with xulfaces. I've
> come across the following problems, some of which I have fixes for. Your
> input would be appreciated, hope I can check some of the stuff in.
>
>  1) As I mentioned in the shale user mailing list, when the validator script
> gets rendered, it outputs raw Javascript inside the <script> tags. The
> Javascript includes characters like & which need to be escaped or in a CDATA
> section in XML. For XUL or XHTML, this is a problem. I guess that XHTML
> parsers are more lenient about this so that's why the problem never showed
> up? Anyway the fix, which was also suggested by Gary VanMatre, was to
> enclose the script contents in an XML CDATA section. So in
> src/main/java/org/apache/shale/validator/faces/ValidatorScript.java
> I have:
>
>  private void writeScriptStart(ResponseWriter writer) throws IOException {
>      writer.startElement("script", this);
>      writer.writeAttribute("type", "text/javascript", null);
>      writer.writeAttribute("language", "Javascript1.1",
> null);
>      writer.write("\n");
>          // jtsay added
>      // Enclose XML in CDATA so special characters can be used without
> escaping.
>      if (!"text/html".equals(writer.getContentType())) {
>          writer.write("<![CDATA[\n");
>      }
>    }
>
>  and
>
>  private void writeScriptEnd(ResponseWriter writer) throws IOException {
>     // jtsay added
>      if (!"text/html".equals(writer.getContentType())) {
>          writer.write("\n]]>\n");
>      }
>              writer.write("\n");
>      writer.endElement("script");
>   }
>
>  This assumes if we are not rendering text/html, we must be rendering some
> sort of XML. Sound reasonable?
>
>
>  2) It seems strange the way that configuration rules are loaded. If the
> default configuration file is not found, the validator lifecycle listener
> will add the default configuration file to the end of a url list. However,
> since the list is processed in forward order, that means if you leave out
> the default configuration file, any settings you have in your own file will
> be overwritten by the default. That means you need to explicitly put the
> default configuration file in your
> org.apache.shale.validator.VALIDATOR_RULES list before your
> own files. Since I think it makes more sense to have your specified
> configuration files override the default settings, I propose the following
> change in ValidatorLifeCycleListener:
>
>
>  private ValidatorResources
> validatorResources(ServletContext context)
>      throws IOException, SAXException {
>
>        // Process the explicitly configured resources (if any)
>       // jtsay
>        // Since we want to add to the beginning later, use a linked list
>        // ArrayList urls = new ArrayList()
>         LinkedList urls = new LinkedList();
>
>
>         ...
>
>
>       // Process the default configuration resources (if not already loaded)
>        if (!didDefault) {
>            try {
>                url =
> context.getResource(Globals.DEFAULT_VALIDATOR_RULES);
>            } catch (MalformedURLException e) {
>                throw new
> IllegalArgumentException("MalformedURLException:"
>                        + " The URL '" + Globals.DEFAULT_VALIDATOR_RULES
>                        + "' specified as a validator rules resource is
> malformed.");
>            }
>            if (url == null) {
>                url =
> ValidatorLifecycleListener.class.getResource(Globals.DEFAULT_VALIDATOR_RULES);
>            }
>            if (url == null) {
>                throw new
> IllegalArgumentException(Globals.DEFAULT_VALIDATOR_RULES);
>            }
>                   // jtsay
>            // Add to beginning of list so that explicit resources override
>            // default, not the other way around.
>            urls.addFirst(url);
>        }
>
>  3) Finally, I'd like to see the ability to override the validation error
> handler. Currently, with the default validatorUtilities.js, whenever a
> validation error occurs, an alert is displayed. To me that is a bit
> unpolished; I'd rather see some message below the input field that has an
> error. Although it's easy enough to replace validatorUtilities.js,
> jcv_handleError() simply doesn't get enough information in its arguments to
> do much with the DOM tree, unless the ID's of the elements to replace are
> hardcoded. It would be good also to let the user supply his own error
> handling script in the JSF tags, instead of messing with replacing
> validatorUtilities (which would be apply across the entire web app anyway).
> Any ideas on how to do this? Is anyone else interested in getting rid of
> alert()?
>
>  Thanks,
>
>  Jeff
>
>