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

[André Bargull]

Concerning states:
How do you want to define the constraint-method on the the parent 
class/instance, if you don't know the parent at compile time?
-> People also instantiate classes dynamically at runtime instead of 
using solely declarative xml-programming.

For example, you've got a view and you want to make that view draggable 
by attaching a dragstate to it:
<canvas debug="true" >
 
  <class name="testview" >
    <attribute name="dragger" />
    <handler name="onmousedown" >this.dragger.apply()</handler>
    <handler name="onmouseup" >this.dragger.remove()</handler>
  </class>
 
  <testview width="100" height="100" bgcolor="blue" clickable="true" >
    <handler name="oninit" >
      this.dragger = new lz.dragstate(this);
    </handler>
  </testview>
 
  <testview x="150" width="100" height="100" bgcolor="red" 
clickable="true" >
    <dragstate name="dragger" />
  </testview>
 
</canvas>


On 2/8/2008 3:59 PM, P T Withington wrote:
> 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?
>>>>
>>>
>>>
>
>