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?
