On 2007-08-06, at 21:36 EDT, Max Carlson wrote:
From my email on Friday:
> Per the call this afternoon (and as signed off by David) we will
add a
> new method to LzNode called setData().
>
> LzNode.setData(dataelement) is called by the replicator immediately
> after the .data property is set and ondata is sent, but before
> applyData() is called on the node being replicated. By default,
> setData() creates a new datapath for the replicated view (if one
doesn't
> already exist) and it always sets the view datapath to the new
> dataelement passed in.
>
> This approach allows replicated views to use $path expressions and
> support datapath bindings out of the box. setData() can still be
> overridden on an instance or subclass of node to do something more
> efficient (like read the data directly and set attributes).
I didn't expect a setter to be added. I thought we'd just add the
setData() method to LzNode and follow the contract above. The
change I made to replicator now does this.
Surely you can understand my confusion. Elsewhere in the system,
when we define setFoo and foo, it is standard for setters.foo to be
'setFoo'. In fact, I now find it utterly confusing that we have a
setData method that is not the setter for the data attribute.
After looking closer at what LzDatapath does now, maybe setData()
should be emulating the behavior of LzDatapath.__LZApplyData(). Do
you think some or all of LzDatapath.__LZApplyData() should be
hoisted up to LzNode (instead of applyData)?
I'm not sure I follow. __LZApplyData is how a datapath applies its
data to the node that encloses it. What would it mean for one node
to apply its data to its parent node? When would this happen?
[...]
