It would be better (we could more efficiently compile, and hence the
back-end compiler/runtime could be more efficient) if this could be
done declaratively. I thought that was the point of a dragstate, that
it was declarative and could be applied or not as necessary?
We can always support the crazy dynamic things that you could get away
with in JS1 runtimes. JS2 instances still have prototype attributes
that behave just as dynamically as JS1 attributes. There will just be
a trade-off: if you do things dynamically at run time, they will not
be as efficient. Right now, we are compiling the LFC classes as
sealed, but then creating a dynamic subclass that can be extended by
LZX class definitions, so dynamic is the default. Maybe some day we
will change that, or give the LZX programmer a choice.
On 2008-02-08, at 10:29 EST, André Bargull wrote:
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?
