#36 setvalue, instance/@src, bind/@readonly

open
None
6
2010-08-11
2010-08-03
No

As reported in email

Also, it seems that binds at levels other than the root node fail as well, but not all of them.

The following combination fails in the dataisland branch, tested with r443 and r445:

<instance id="main" src="foo.xml" />
<instance id="controls"><data xmlns=""><locked>false</locked</data></instance>

<bind nodeset="instance('main')" readonly="instance('controls')/locked='true'" />

<trigger>
<label>Edit</label>
<setvalue ev:event="DOMActivate" ref="instance('controls')/locked">false</setvalue>
</trigger>

The setvalue event happens, but the value of locked never changes, and the readonly MIP does not change.

The setvalue and MIP work OK when loading instance id="main" from inline content, but not from @src.
The setvalue works when the bind/@readonly is removed.
The setvalue and MIP work OK when the bind nodeset="instance('main')/BufferSize", but not when it's inherited from root.

Since XSLTForms has the non-standard restriction on one bind per node, it's important that the MIP inheritance and binding to instance root element work.

See the attached files showing the above examples complete.

Discussion

  • setvalue fails example

     
    Attachments
  • setvalue works example

     
    Attachments
  • setvalue works also example

     
    • priority: 5 --> 6
     
  • I believe this is caused by Core.setBoolMeta and friends, which dynamically change attributes during evaluation, and for() loops which are iterating over the attributes get a distorted view of the attributes.

    The attached example fails because it gets an "undefined" error in XFInstance.prototype.validation_:

    if (atts[i].nodeName.substr(0,10) != "xsltforms_") {

    atts[i] is undefined, even though it's inside a for loop:

        for \(var i = 0, len = atts.length; i &lt; len; i++\) \{
                if \(atts\[i\].nodeName.substr\(0,10\) \!= "xsltforms\_"\) \{
                    this.validation\_\(atts\[i\], readonly, notrelevant\);
                \}
    

    The var len no longer matches with atts.length; it's now longer than atts.length.var

    I believe this is because, during the above recursive calls to this.validation_, this eventually happens:
    this.setProperty_(node, "notrelevant", notrelevant);
    this.setProperty_(node, "readonly", readonly);
    this.setProperty_(node, "notvalid", schtyp && !schtyp.validate(value));

    That causes Core.setBooleMeta to be called, which alters the attributes on the element, and so the array iteration fails.

     
  • Workaround using copy of attribute names list; also includes nodeType fix from 3042659

     
    Attachments
  • changes2.txt contains
    a workaround using copy of attribute names list;

    It also includes nodeType fix from 3042659 because it depends on that fix.

     
    • assigned_to: nobody --> alain-couthures
     
  • Please review.