I like this proposal so much!
Man, it would make my job so much easier!
What's the status of this proposal?
jrs
On Dec 6, 2005, at 6:35 PM, Jim Grandy wrote:
Man, the formatting came out really bad for this. Here's something a
bit more readable:
This is nothing new, says Max, but it's new to me so I'd like to
discuss it anyway. I think something like this would substantially
improve usability of view replication.
Consider this basic replicated view declaration:
<view name="top">
<view>
<datapath xpath="..." replication="normal" pooled="false"/>
</view>
</view>
That declaration generates this runtime node hierarchy:
LzView { name: "top" }
LzReplicationManager { datapath: «…», pooling: false, cloneClass:
'LzView', cloneAttrs: {...} }
LzView { clonenumber: 0 }
...
LzView { clonenumber: n-1 }
Look at how poorly the declaration structure maps to the runtime
structure. In the declaration, replication type is an attribute of the
datapath, which is an attribute of the clone prototype. In the
runtime, the datapath is an attribute of the replication manager, as
is the clone prototype. Also note that you have to spot a datapath
declaration in a view to know whether might be intended to be
replicated -- an indirect indicator at best since the view is only
replicated if the datapath matches multiple nodes.
Let's imagine what a cleaner design might be for this. Why not design
the declarative syntax to more directly match the runtime hierarchy?
<view name="top">
<replicated pooled="false">
<datapath xpath="..."/>
<view />
</replicated>
</view>
What are the advantages of this approach?
1. nesting in XML more closely matches nesting at runtime
2. @pooled and datapath are declared as an attribute of the
replication manager where it belongs
3. we can supply attributes to the replicator in XML source instead of
tacking them onto datapath
4. we also have more flexibility about specifying the clone prototype:
inline, as above -- where it could be a true prototype -- or by giving
@cloneClass and @cloneAttrs (not possible in the old schema without
adding datapath attrs)
5. LzReplicationManager construct function can be simplified since we
aren't doing as many tree restructurings
6. it resolves LPP-780, which asks for a way to force replication even
if a datapath only matches one node
7. It also resolves the request in LPP-908 that oninit/ondata be
distinct between replication manager and clone
9 It responds to Adam's criticism in
(http://www.laszlosystems.com/~adam/blog/archives/000017.html) that
the first view in a replicated view sequence is "special". The view
prototype is insulated from being instantiated in this new scheme, and
is truly only used as a prototype -- and could in fact be a prototype,
or a "private" class in a more class-based scheme.
Further notes:
* I'm not totally in love with the "replicated" name, but it does
match the declarative style better than "replicate" or "replicating"
* In this scheme, selecting a lazy replication manager would be done
using a different tag, "lazyreplicated" instead of "replicated"
* Or, a bit more complex to implement, we could add an @type attribute
to the replicated tag.
* we could stage this by support both old and new syntaxes,
deprecating the old, and ending up with datapath attributes in nodes
being required to match a single node. I'm probably missing some
complexities here, though.
* Replication should work over nodes, not just views.
By the way, LPP-908 asks for three things. My proposal only addresses
the second, but we should do the other two as well.
* Replication managers should be able to have constrained datapaths.
* There needs to be a clear distinction between the oninit of the
replication manager, and the oninit of a clone, same for ondata.
* Each clone ought to have a pointer to its replication
manager._______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
