Hi Alain and everyone :)
I've spent some time integrating my software with XSLTForms, and I feel
this has been a good use of time. I had integrated with EMC Formula
before, but XSLTForms seems to have all the XForms-y goodness that I
require, with a nice open source license. I really appreciate this project.
I've hardly got my feet wet with xsltforms.js, but I was able to find out
why values in my form were marked as invalid even though they were valid.
If @*xsi:nil* is given as 'false', *XsltForms_browser.getNil()* will return
true, because *XsltForms_globals.booleanValue('false')* returns true
because 'false' is a string with length > 0.
This new version of *XsltForms_browser.getNil()* behaves the same as
before, except that it returns false if @*xsi:nil* is given as 'false':
XsltForms_browser.getNil = function(node) {
if (node.nodeType !== XsltForms_nodeType.ELEMENT) return false;
var att;
if (node.getAttributeNS) {
att = node.getAttributeNS("http://www.w3.org/2001/XMLSchema-instance";,
"nil");
} else {
att = node.selectSingleNode("@*[local-name()='nil' and
namespace-uri()='http://www.w3.org/2001/XMLSchema-instance']");
if (!att || (att.value === "")) return false;
att = att.value;
}
return XsltForms_globals.booleanValue(att) && (att !== "false");
};
The context for this is that I use @xsi:nil to make it clear which elements
have values which do not, which is helpful to me in the context of forms
processing. It's simpler to just include all the elements which may have
values, and specifying @xsi:nil='true' means it's clear there's no value,
even though the element is present. One would not typically specify
@xsi:nil='false', but it's valid to do so, and in this context of working
with forms, I find it helpful for values which may *become* nil.
@xsi:nil is just a static attribute in a document, but it comes alive quite
easily in XForms with this bind:
<xf:bind nodeset='//@xsi:nil' calculate="if(..='', 'true', 'false')"/>
The bind obviously does not work if you want to have an element be empty
and not nil, but I'm OK with not handling that case right now.
I had trouble getting the bind to work, until I realized the problem was
Firefox-specific and I found this page:
http://en.wikibooks.org/wiki/XSLTForms/Known_Restrictions
so I specify @xsi:nil='false' on the root html element and now all is well
on Firefox :)
Something else: it seems that xs:pattern regex can't include a
forward-slash unless I backslash-escape it (which causes validation of the
schema itself to fail), or I can put it in a character set by itself: "[/]"
(which is a good workaround)
For example:
<xs:simpleType name="fraction">
<xs:restriction base="xs:string">
<!--<xs:pattern value="[0-9]+/[0-9]+"/>-->
<xs:pattern value="[0-9]+[/][0-9]+"/>
</xs:restriction>
</xs:simpleType>
It's easy to work around once I found it, but I wanted to mention it.
/Adam
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Xsltforms-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xsltforms-support
