I agree. My question was about whether these things were inherited
along the parent or immediateparent chain. Since you don't know the
immediateparent at compile time, it would be impossible to make any
compile-time optimization. Also, I'm suggesting that if you break
these 'cascading' attributes out into separate objects, they could
use prototype-inheritance to give you memo-izing for nearly free.
Instead of putting the cascading attributes directly on the view, put
them in an object/hash that can have a different inheritance chain
(i.e., the one specified by immediate parent).
'zat making any sense?
On 2006-03-31 15:30 EST, Henry Minsky wrote:
> We have some code that attempts to compute the font size/name/style
> attributes at compile time, which means it has to use a model of
> the default
> attribute values ofr classes, etc. That code is there in
> ViewCompiler to do
> that, and it works but is kind of baroque, so I was leaning towards
> removing it if there would be not a runtime performance impact ; it
> seems
> like optimizing the runtime to memoize the inherited font all along
> the
> parent chain would be step towards increasing the runtime
> efficiency, and
> thus making the compile-time calculations less neccessary.
>
>
>
> On 3/31/06, P T Withington <[EMAIL PROTECTED]> wrote:
>>
>> a) Is the font really determined by the immediate (dynamic) parent?
>> That's annoying because it means you can't compute it at compile
>> time.
>>
>> b) If css properties like this _are_ determined by the immediate
>> parent, then perhaps the props should all be stored in a separate css
>> attribute and we could use proto-based inheritance to do the lookup.
>> E.g., css would be an attribute of view that is a hash, and the
>> hash's __proto__ would be the immediate parent's css hash.
>
>
>
> Is that something which behaves like the DHTML CSS model (which we
> would
> want to use I would think).
>
> On 2006-03-31 09:41 EST, Henry Minsky wrote:
>>
>>> The text class calls
>>>
>>> this.fontname = this.searchParents( "fontname" ).fontname;
>>>
>>> for font name/size/style properties
>>>
>>> searchParents is implemented as
>>>
>>> LzView.prototype.searchParents = function ( prop ){
>>> var sview = this;
>>> do{
>>> sview = sview.immediateparent;
>>> if (sview[ prop ] != null ){
>>> return sview;
>>> }
>>> }while ( sview != canvas );
>>> }
>>>
>>> Would it be more efficient if the searchParents function set the
>>> properties
>>> all the way back down the parent
>>> chain when it found one, so that other calls wouldn't have to
>>> search up past
>>> their first parent? It seems like with the
>>> way the value is filled in now, that wouldn't change the behavior
>>> because in
>>> the current code the font style attributes which are null at
>>> runtime are
>>> found and cached on a text element, and then modifying the parent
>>> has no
>>> subsequent effect on the text font style. So caching the parent
>>> values as
>>> well wouldn't change things anyway.
>>>
>>>
>>> --
>>> Henry Minsky
>>> Software Architect
>>> [EMAIL PROTECTED]
>>> _______________________________________________
>>> Laszlo-dev mailing list
>>> [email protected]
>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>
>>
>
>
> --
> Henry Minsky
> Software Architect
> [EMAIL PROTECTED]
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
