True. And this I think is one of the complaints about implicit
replication, that it is unpredictable.
The alternative is that implicit replication will just have to be
slower than explicit (because it needs to do this dynamic method
detachment and attachment at runtime, rather than being able to be
analyzed at compile time). That would certainly be another way to
deprecate implicit replication! :)
On 2008-02-07, at 17:24 EST, André Bargull wrote:
But you need to consider, that the constraint does not apply to a
replication-manager in every case! If the xpath-expression points to
a single node, replication isn't triggered and therefore no
replication-manager will be created. If you just replace all
constraint datapaths with explicit replication, many programs will
break, because people don't expect to get a replicator-node in this
cases.
Delving into making constraints class methods, we have some tag-
compiler work to do.
Apparently you can say:
<view datapath="${...}" />
or:
<view>
<datapath xpath="${...}" />
In both cases, the constraint really applies to the (invisible)
replication manager, not to the view or the datapath. Right now
this constraint is picked up at run time, ripped off the clone
template and smashed onto the replication manager. That is not
going to work in modern (JS2) runtimes.
I think the right approach here is to have the tag compiler re-
write implicit replication into explicit replication, so:
<view datapath="${...}" />
becomes:
<replicator datapath="${...}">
<view />
</replicator>
etc.
Does this seem feasible? Could we even spit out a deprecation
warning suggesting that explicit replication be used?
