On 2006-09-01, at 20:12 EDT, Adam Wolff wrote:
> Hi Tucker,
> Ben found a bug with using $style in a class definition. Given:
> <class name="super" bgcolor="${ 'stylea1' }"/>
> <class name="sub" extends="super" x="${ 'stylea2' }"/>
>
> An instance of sub doesn't get the styled value. In general, this
> kind of
> thing is handled by passing the collected style attributes as an
> Object,
> which are then attached to the superclass version of the same in
> the ugly
> loop at the top of the LzNode constructor. Since right now, the $style
> attribute is a function, this object composition isn't happening.
>
> Thoughts? Feelings? Seems like the easiest thing to do would be to
> pass
> $styles as a hash.
Yes that magic object-merging loop is truly ugly, and I wouldn't be
surprised if it bites us some day...
$styles is a function so that $style constraints can be an expression.
(Someday, it would be nice if the other constraints could be handled
this way too, rather than the way path expressions are evaluated
(only can be variables or member references), or the way once
constraints have to be passed as individual functions.)
I think the right way to handle this is the same way that setters are
handled. In 3.x that means smashing the __proto__ of the hash to
inherit from the superclass. In 4.x, where we can't do __proto__
smashing, we either have to copy the hash or pass in an empy
LzInheritedHash to $styles to fill in. If we want to be forward-
looking, perhaps we should do the latter in both cases?
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
