wow.  thanks for the great explanation, Tucker!

FYI: in this case constraints are created from script since the class of
the scrollbar to be used is declared as an attribute, so it and its
constraints can't be declared.  Someday, I expect we'll have a solution 
where a scrollbar can be
replaced (skinned) without losing our lovely declarative syntax.

It is odd, given your explanation, that there was no warning that parent 
was undefined.  It is also odd that this seems to have worked in 3.2, 
and I don't see any changes in the revision history since then.  Huh.

On Tue, Jun 13, 2006 at  6:34 PM, P T Withington wrote:

> On 2006-06-13, at 21:03 EDT, Sarah Allen wrote:
>
>>
>> ok, I just code reviewed a fix in scrollrichedittext that I don't 
>> really
>> understand.  Perhaps one of the Javascript gurus on the list can
>> enlighten us.
>
> More than just Javascript.  There is lots of LZX black magic here.
>
> One wonders why you are having to call applyConstraint in the first 
> place rather than using a declarative constraint?
>
>> The following code generated a waring that inp was undefined:
>> this.applyConstraint("stepsize",
>>                          function() { this.setAttribute("stepsize",
>> parent.inp.lineheight); },
>>                          [p.inp, "lineheight"]);
>
> I'm surprised there was not a warning that `parent` was undefined. But 
> maybe there is a global named `parent`.
>
>> The bug was fixed by adding an explicit 'this' before parent.inp:
>> this.applyConstraint("stepsize",
>>                          function() { this.setAttribute("stepsize",
>> this.parent.inp.lineheight); },
>>                          [p.inp, "lineheight"]);
>
> This looks like it still has a bug, but maybe you are not telling me 
> that p == parent in this context.
>
>> My first thought was... I thought you never needed an explicit this 
>> for
>> parent since it is defined at construct time.
>
> You would not have if you used a declarative constraint, because 
> declarative constraints are implicitly evaluated in a `with (this)` 
> context.  [Seemed like a good idea at the time, but we really regret 
> that we ever did that.  It has caused no end of pain.]  Since you are 
> creating your constraint by hand, you need to explicitly say 'this' 
> where you mean it.  (Or you could have put the function body inside 
> `with (this)` which is what the tag-compiler does.)
>
>> My second thought was... um, what the heck is 'this' in the middle of 
>> an
>> anonymous function?
>
> More magic.  A constraint function is evaluated as:
>
>    <constraint>.call(this);
>
> So that 'this' in the constraint is the object that has the 
> constrained attribute as a member.
>
>> I would have thought it was no longer in the scope
>> of the object.  Why does this work?
>
> If you said:
>
> <attribute name='stepsize' value='${parent.inp.lineheight}' />
>
> and compiled that using `lzc --script` you will see all the magic.

_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user

Reply via email to