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
