Re: Shale validator wish list

> 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
>
>