[Laszlo-dev] Implicit replication, <view> datapath property, and, <datapath> xpath property

P T Withington ptw at pobox.com
Fri Feb 8 04:46:30 PST 2008


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?
>




More information about the Laszlo-dev mailing list