When I inspect the textlistitem, it's text value is "<item label="Two"/> ",
which will show up as empty in a text field because it looks
like an HTML tag.
You're seeing the serialized data-element, try to eval
"gConfigsList.interior.content.subviews[0].text" to see the difference.
Tricky debugger! :-)
When <replicator> sets up the clones, it calls setData() for each clone,
here's a simplified call stack to demonstrate what is actually happening:
<replicator>#setData() calls <node>#applyData(), <basecomponent>
overrides applyData() and in turn calls <basecomponent>#acceptValue(),
<basecomponent>#acceptValue() calls <node>#setAttribute('text',...).
So, the "data" (in this case the data-element) is assigned to the "text"
attribute, well that's not really wanted.
<node>#applyData() is only called to mimic <datapath>, see
<datapath>#__LZApplyData(). But <datapath>#__LZApplyData() is doing a
bit more than just calling applyData(), for example it checks the
datapath's xpath, because the actual contract for <node>#applyData()
(and its counterpart <node>#updateData()) is a bit different. Buried
deeply in <datapath>#updateData() we find this description:
If the current datapath's xpath ends in a terminal selector (an attribute,
text(), or name() expression), then the datapath attempts to call its parent's
updateData method.
Checking <datapath>#__LZApplyData() again:
[...]
var ppath:LzParsedPath = this.parsedPath;
if (ppath && (ppath.operator != null || ppath.aggOperator != null)) {
ip.applyData( this.data );
}
Ok, operator != null or aggOperator != null, that's what? Looking up in
LzParsedPath:
/**
* One of: "name", "text", "serialize", "attributes"
* or "attributes.xxx" with 'xxx' as an attribute-name
*
* @access private
*/
var operator:String = null;
/**
* One of: "position" or "last"
*
* @access private
*/
var aggOperator:String = null;
Aha, that's the implementation of the <datapath>#updateData() contract
(= xpath with terminal selector).
This part wasn't copied over to <replicator>, because there is no easy
way to get the parsed xpath. Lazy developer?
And here's the updated version of <replicator>#setData() which fixes
this issue. (The internal <datapointer>#parsePath() is required to get
the LzParsedPath instance.)
<method name="setData" args="v:*,n=null"><![CDATA[
if (v) {
v.setAttribute('data', this.nodes[ n ]);
var ptr = this._pointer;
if (ptr) {
var ppath = ptr.parsePath(this.xpath);
if (ppath && (ppath.operator != null || ppath.aggOperator != null)) {
v.applyData(this.nodes[n]);
}
} else {
// other data-source
v.applyData(this.nodes[n]);
}
}
]]></method>
On 10/29/2010 12:30 AM, Henry Minsky wrote:
Hi Andre,
I noticed you commented on a similar replicator issue (LPP-9419) and was
wondering if you had any idea
why the test case in LPP-9474 works when I add a <view> around the
<textlistitem>
--
Henry Minsky
Software Architect
[email protected] <mailto:[email protected]>
