When I have to write constraints manually, I usually just write a method
that updates the constraint, and then manually register a delegate for the
dependencies. There's no advantage to using applyConstraint.
A
On Jun 13, Sarah Allen wrote:
> 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
>
_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user
