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.
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)?
P T Withington wrote:
I guess I am confused. It seems that if you have a datapath (which any
node can?) then you might have your data attribute set and your
applyData method will be called. If you don't have a datapath, you can
feel free to have a data attribute and it will not be mucked with.
Your solution to the issue of how replicators set the data context of
their children of last week was that they would set the data attribute
and that we would have a setter for node that would coerce that into a
data context.
We discovered that is no good, because there are subclasses of node that
expect to be able to have a data attribute -- so a general setter on
data is not going to fly. This is too bad, because it seems the more
LZX-y thing to do would be to get rid of applyData and only have a
setter on data.
Instead, it looks like what we should do is hoist applyData up to node
and use that pattern. <sigh>
On 2007-08-06, at 19:49 EDT, Max Carlson wrote:
Which behavior did you hoist up from text? The only difference
between LzText and LaszloView I see is the implementation of applyData().
It looks to me like .data is set in LzDatapath.__LZApplyData().
LzDatapath.__LZHandleDocChange() also appears on .data being set.
P T Withington wrote:
FTR,
The problem is that we hoisted data up from text to node, but
databinder (a subclass of node) already defined a data attribute. As
Max points out, it would be nice to have consistent behavior for the
meaning of the data attribute on nodes.
Some alternatives:
1) Make data a reserved property of node, fix all subclasses of node
to deal with that.
2) Use a different name for this property, fix text to use that
different name.
3) Only hoist data up to view, since replicators only replicate views.
Other ideas?
On 2007-08-06, at 17:46 EDT, Pablo Kang wrote:
Looks good. Adding a comment why setData isn't a setter for the data
attribute would help. Alternatively, rename setData to something
else and comment what that method does exactly. In particular, how
it creates a datapath if one doesn't already exist.
pablo
On Mon, 6 Aug 2007, Max Carlson wrote:
Change 20070806-maxcarlson-x by [EMAIL PROTECTED] on 2007-08-06
14:30:15 PDT
in /Users/maxcarlson/openlaszlo/wafflecone
for http://svn.openlaszlo.org/openlaszlo/branches/wafflecone
Summary: Remove setter for LzNode.data
New Features:
Bugs Fixed: LPP-4405 'Implement ExplicitReplication' (partial)
Technical Reviewer: promanik
QA Reviewer: ptw, pkang
Doc Reviewer: (pending)
Documentation:
Release Notes:
Details: LzNode.lzs - Remove setter for .data -> setData().
replicator.lzx - Call v.setData( this.nodes[ n ] ); instead of
setAttribute('data', ...)
Tests: silver/main.lzx?lzr=swf8 runs again,
http://localhost:8080/wafflecone/test/explicit-replicators/replicator.lzx?lzr=swf8
passes
Files:
M WEB-INF/lps/lfc/core/LzNode.lzs
M lps/components/utils/replicator/replicator.lzx
Changeset:
http://svn.openlaszlo.org/openlaszlo/patches/20070806-maxcarlson-x.tar
--
Regards,
Max Carlson
OpenLaszlo.org
--
Regards,
Max Carlson
OpenLaszlo.org
