P T Withington wrote:
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.
I do. Perhaps we should name setData to setReplicatorData or something
more descriptive.
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?
It seems like LzNode.setData() and LzDatapath__LZApplyData() do many of
the same things. Perhaps some of this functionality could be moved to
LzNode and shared.
--
Regards,
Max Carlson
OpenLaszlo.org
