Thread: [Xsltforms-support] fix: XsltForms_browser.getNil() returns true when @xsi:nil is specified as 'fal
Brought to you by:
alain-couthures
From: Adam M. <Ada...@gm...> - 2012-06-08 02:07:03
|
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 |
From: Alain C. <ala...@ag...> - 2012-06-13 04:24:23
|
Hi Adam, About XsltForms_browser.getNil(), I know consider that return att !== "false" is enough and much better indeed... I also changed the way restrictions are transformed so the slash characters in them are escaped with a back-slash before. Those fixes will be committed as soon as possible. Thanks! -Alain Le 08/06/2012 04:06, Adam McKee a écrit : > 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' > <http://www.w3.org/2001/XMLSchema-instance%27>]"); > 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 > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support |