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 <[EMAIL PROTECTED]> 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 > >
