Closed backplane-import closed 12 years ago
To be more specific: the only changes needed to fix this issue are the changes to isEnabled() in mip-handler.js and the changes in xforms.js (adding XFormsProcessor.getContextNode and XFormsProcessor.hasContextNode)
The reasoning behind using the context node is that, for an xf:output with an @value inside a repeat, the context node should in theory point to whatever the @ref is pointing to. I'm not 100% sure about this though, so correct me if I'm wrong.
Also, not to spam my own ticket, but I'm not sure why this happens inside a repeat but not in the other mip-enabled functional test. My best guess is that it has to do with the order of decoration and consequently the refresh / rewires that occur before the model is ready, which is why I have all those "if (!this.model.m_bReady)" conditionals in that changeset. That might be a cleaner way to address the problem.
This issue was updated by revision 0e9c3e26f471d30420b2a862160bdb7830fb1065 (originally 3db84ec105).
Added functional tests to show this issue failing.
This issue was closed by revision e81a949d3af67a4ffe2cbb0d9b833cab953433ad (originally ba768bad68).
Updates
Ticket status set to Fixed
Imported from backplanejs Google Code issue 94.
What steps will reproduce the problem?
What is the expected output? What do you see instead? Control is disabled when it should be enabled
Functional test can be found at http://code.google.com/r/fdintino-backplanejs/source/detail?r=97a3ddb2b25f976a138a7a3f9f148346ca3e3ef9#
Fix can be found at http://code.google.com/r/fdintino-backplanejs/source/detail?r=0da1dc201831121aae66a61bd70550e4239db53b
Owner set to fdintino
Priority: Medium Type: Defect