search

sidewinderlabs / backplanejs

Other
12 stars 3 forks source link

isEnabled() returns incorrect value for xf:output with @value attributes #88

Closed backplane-import closed 13 years ago

backplane-import commented 13 years ago

Imported from backplanejs Google Code issue 88.

Reporter fdintino
Date 30 Jul 2010 12:22:05 AM UTC

What steps will reproduce the problem?

  1. Load the sample form

What is the expected output? What do you see instead?

  1. Neither outputs should have the "disabled" class name. They both point to the same node, one without a value attribute and the other with value="concat('', .)", so they both should be enabled.
  2. Instead, the output with a value attribute has the "disabled" class name, as indicated by it's 50% opacity and gray background.

Priority: Medium Type: Defect

backplane-import commented 13 years ago

Update by fdintino on 30 Jul 2010 12:24:23 AM UTC

Attachments

test-isenabled-oval.html (1.4 KB)

backplane-import commented 13 years ago

Comment by fdintino on 30 Jul 2010 12:49:23 AM UTC

Fix in http://code.google.com/r/fdintino-backplanejs/source/detail?r=0da1dc201831121aae66a61bd70550e4239db53b

Updates

Ticket status set to FixPending

backplane-import commented 13 years ago

Comment by markbirbeck on 1 Aug 2010 6:17:25 PM UTC

This is a tricky bug. I can see that the fix is useful, but if we are following the letter of the XForms spec, I can't think of a scenario where it would be applied.

If I explain the context, the mark-up that has been provided in the attachment doesn't do what it appears to do; when processing something like this (extract from the functional tests for output, mentioned below):

xf:labelOutput with @value and concat():/xf:label /xf:output an XForms processor is supposed to _ignore_ the @value attribute. This means that it should have the same effect as if we had written this: xf:labelOutput with @ref:/xf:label /xf:output As you can see from revision f840e36abc11985dae6034f92aea27168182e298 (originally [430cff4b3a](http://code.google.com/p/backplanejs/source/detail?r=430cff4b3a)) which includes functional tests for @ref, @value and so on, the processor passes the tests. I'm therefore closing this issue as being not a bug (i.e., 'Invalid'). However, if anyone can think of a scenario where something sets its own evaluation context for other attributes, then we can certainly add the fix. It would probably be a new issue though, and would require new functional tests. --- **Updates** Owner set to --- Ticket status set to **Invalid**