On 2010-02-10, at 14:47, Rami Ojares wrote:
> Hi,
>
> Here is a piece of typical OL xml
>
> <SomeClass height="${this.program.duration * x + y}">
> <attribute name="program"/>
> </SomeClas>
>
> This creates automatically a handler something along these lines
>
> <handler name="onduration" reference="this.program" args="newDuration">
> this.setAttribute("height", this.program.duration * x + y);
> </handler>
>
> In my app it is very common that not only the duration of the program changes
> but also the program
> attribute of SomeClass changes too.
>
> That's when things go wrong.
This was a conscious implementation decision, to keep our constraint system
bounded. We experimented with automatically handling (what I call) "path"
expressions, but the overhead was too great (simply because it created so many
delegates). Most use-cases seem to be covered by the simple implementation of
constraints.
This is documented, although perhaps obscurely: http://bit.ly/9wDhNU
Usually, you can work around issues like your example by making your constraint
a little more careful:
height="${this.program ? (this.program.duration * x + y) : 0}"
But for complex dependencies, you do just have to write them out by hand.
Another thing to consider is that constraints are wonderful for prototyping,
but they can end up bogging things down if you get too many going at once.
Often after you have your system prototyped and working, it is worthwhile going
over it to see if there is a more imperative way to cast the solution, perhaps
by inverting the logic: rather than a constraining to b, have b tell a when it
needs to update. Sometimes b can make a much better decision on when a should
update than a can by watching b for changes.
