[Laszlo-dev] Attribute value overriding [Was: For Review: Change 20090109-hqm-3 Summary: make debugger set position to be on screen]

[P T Withington]

On 2009-01-11, at 11:27EST, André Bargull wrote:
> On 1/11/2009 4:04 PM, P T Withington wrote:>
>> It's generally a mess.  I don't think anyone has thought out what  
>> really ought to happen, instead, the mechanism has just sort of  
>> evolved as applications have needed to do different things.  The  
>> debugger console window is a really good test case, because we  
>> really want some default constraints, but those should be  
>> overridable by use values _or_ constraints, and on top of that,  
>> when the drag or resize states come into play, you really want to  
>> remove _any_ constraint (default class or instance).
>
> Would it help if both instance and class constraints were removed  
> when a state is applied? That way you can install a default  
> constraint (can be done in the class), this can be overridden by an  
> instance value (both constant and constraint) through the normal  
> override behaviour in LzNode and you don't get any problems when one  
> of the states get applied.

Yes, that would make my original proposal to Henry, that when the  
resize state was applied it would simple define x/y to be their  
current values (thereby removing any constraint) work.  It did not  
work because the constraint on x/y was a class constraint.

If we did make states remove class constraints too, then I think we  
could keep __LZhasConstraint private (and not have to provide any  
additional mechanisms for removing constraints).

Then the programmer model for the LZX programmer becomes quite simple:

1. A class can give an attribute an initial value, which may be a  
constant or a constraint.

2. A subclass or instance can override an attribute initial value,  
again with either a constant or constraint.

3. A state (when applied) can override both 1 and 2, again with a  
constant or constraint.

Our current understanding is that when a state is removed, it does not  
'reveal' the value that it overrode (whether constant or constraint),  
it simply leaves the attribute with its current value.

---

I think this is a nice model because you never have to write anything  
but a declarative

   <attribute name=... value=... />

to manipulate an attribute.

The way you override a constraint on an attribute is to override the  
attribute with a new value.

The way to dynamically do that, is to put your override in a state.

---

The only question is, whether we would break something with this more  
uniform model.  I'm betting we would not.  It's possible that this  
model is more how 3.x worked (whether by design or by accident).  But  
I certainly like the simplicity of the programmer model this provides!