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

[P T Withington]

What I'm working on right now is unifying attribute initialization.   
Rather than having separate lists of initial values, initial  
expressions/constraints, and style constraints, I am creating a single  
list and using classes to distinguish what type of initialization (or  
constraining) happens to each attribute.  This should solve the  
problems we have with literal overriding a constraint, etc., which all  
stem from the runtime not being able to compute how the separate lists  
interact up the inheritance chain.  This is part of the groundwork to  
have LZX classes output as JS2 class declarations at compile time,  
rather than the current 'template' that the instantiator reads to  
create classes at run time.

As part of this work, and part of the JS2 work, I am changing the tag  
compiler to, instead of outputting constraints as free-floating  
functions that get call/apply-ed to specific instances, to output them  
as methods on the correct class.  This is mostly an efficiency thing.   
We still could move these constraint methods around if we had to, I'd  
just like not to have to, because method calls should be more  
efficient than applying a random function to an instance.

Finally, I think I have a fix to make `releaseConstraint` actually  
work, that falls out of the above changes.  That code had totally  
rotted, as you will see in the comment, yet there are a number of  
places that either expect it to work or should be using it.  (For  
example, if you try to change the `align` or `valign` of a view, you  
probably get really unexpected results -- the current code applies a  
constraint for the new value, but the old constraint is not released.   
If it works at all, it is through serendipity of the order in which  
the constraints are fired.)

So, states:  I think for a state, if there are constraints in the  
state, the constraint method will be defined on the parent class/ 
instance, and the constraint apply/released as the state is applied or  
not.

And for implicit replication, yes, I agree, it is probably a matter of  
moving the constraint method to the instance/class it will be applied  
to (at compile time), and at run time, you may or may not actually  
instantiate the replication manager.

On 2008-02-08, at 08:41 EST, André Bargull wrote:

> What do you actually plan to do for states, because through states  
> you'll get dynamic constraints, so dynamic method attachment/ 
> detachment, too.
> You've wrote once about a LzConstraint-class, but I can't quite  
> remember in which context. If you had this LzConstraint-class,  
> couldn't you add/remove constraints more easily at runtime?
> So specifically for implicit replication, you'd only remove the  
> datapath-/xpath-constraint from the source-node's datapath and  
> attach it to the replication-manager and that's it.
>
> Also keep in mind, that currently constraint datapaths aren't fully  
> "bug-free", i.e. LPP-4209 or LPP-5353.
>
> On 2/8/2008 1:46 PM, P T Withington wrote:
>> 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?
>>>
>>
>>