I think the simplest solution would be for me to redefine the $styles
method as follows:
function $styles () {
var map = super.$styles();
var styles = { ... };
for (var k in styles) { map[k] = styles[k]; };
return map;
}
That means you need a default $styles method on LzNode that returns a
_new_ empty hash;
And you call __LZapplyStyleMap on this.$styles().
---
We can make this more efficient by caching the style map on classes
in user class.
How does that sound?
On 2006-09-03, at 00:17 EDT, Adam Wolff wrote:
> If we did use LzInheritedHash, when would we retrieve the unmasked
> version
> for each class? We'd need the new class initializer too, right?
>
> On Sep 2, P T Withington wrote:
>
>> On 2006-09-02, at 18:37 EDT, Adam Wolff wrote:
>>
>>> I think we're saying the same thing. FWIW $path expressions are
>>> passed as
>>> written -- with or without quotes -- and the runtime parses them.
>>
>> We should consider doing them the way $style is done. Then you
>> can have a
>> general expression, and they would all be done at once.
>>
>>> I'd rather just implement proto smashing for now and fix it in
>>> legals
>>> later, rather than port LzInheritedHash to coal.
>>
>> If you're pressed, fine. It will just make it harder to port CSS
>> to Legal's.
>> LzInheritedHash is trivial, BTW:
>>
>> //---
>> // @keywords private
>> // Used to efficiently clone hashtables using Object's
>> // N.B. these tables incorrectly will appear to have entries for all
>> // the properties of Object.prototype. To avoid this (but pay the
>> // of a slower implementation, use LzDictionary).
>> //---
>> LzInheritedHash = {
>> make: function make (parent) {
>> if (parent) {
>> function xtor() {};
>> xtor.prototype = parent;
>> return new xtor();
>> }
>> return new Object;
>> }
>> }
>>
>>> On Sep 2, P T Withington wrote:
>>>
>>>> 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
