Clever indeed -- kudos to Tucker!
This would put the "cascade" in our style model with very little
effort. Nice.
Two questions to pursue: how different would this be from our current
style feature? And: how different would this be from w3c css? I'm not
sufficiently up to speed on either to be able to answer these
questions without some research.
jim
On Mar 31, 2006, at 9:30 PM, Neil Mix wrote:
> That's very clever. And I'm humbled -- you just taught me something
> about JavaScript that I didn't previously know. This language slays
> me -- after 4 years of it I still don't have it down. :/ Neat.
>
> On Mar 31, 2006, at 5:33 PM, P T Withington wrote:
>
>> On 2006-03-31 17:59 EST, Neil Mix wrote:
>>
>>> That looks a lot like a cloning operation:
>>>
>>> function cloneObject(obj) {
>>> var clone = {};
>>> for(var n in obj) {
>>> clone[n] = obj[n];
>>> }
>>> return clone;
>>> }
>>
>> Except the clone will not track changes in the object it was cloned
>> from. By using the prototype chain, if a view inherits a style
>> from its parent and the parent's style changes, the view would see
>> it too. (Hm, but there would still need to be an event sent to
>> tell the child view to notice the change...) [Note in my code I
>> set the css object to have the parent object as it's prototype, and
>> then set the local values from the init args into the local css,
>> which will cause them to override any in the parent. If you want
>> to dynamically revert an overridden style to inherit from the
>> parent, you just delete it and the parent value will be exposed.]
>>
>>>>> use prototype-inheritance to give you memo-izing for nearly free.
>>>
>>> By "for nearly free" do you mean "without performance overhead"?
>>
>> I mean, the chasing up the immediateparent chain would be done in
>> the runtime (presumably _much_ faster than could be done by a
>> Javascript for loop).
>>
>>> On Mar 31, 2006, at 3:23 PM, P T Withington wrote:
>>>
>>>> I believe so. I'm thinking you do something like this:
>>>>
>>>> // How to make a new object with an existing object as its
>>>> prototype
>>>> // in standard Javascript
>>>> function makeNewObjectWithAnotherObjectAsItsPrototype
>>>> (anotherObject) {
>>>> var xtor = function () {};
>>>> xtor.prototype = anotherObject;
>>>> return new xtor();
>>>> }
>>>>
>>>> // Assuming the css attributes of a particular view are passed as
>>>> a hash
>>>> // named style: in initargs
>>>> View.init = function (initargs) {
>>>> var style = initargs['style'];
>>>> var css = makeNewObjectWithAnotherObjectAsItsPrototype
>>>> (immediateparent.css);
>>>> for (var k in style) {
>>>> css[k] = style[k];
>>>> }
>>>> this.css = css;
>>>> }
>>>>
>>>> On 2006-03-31 16:01 EST, Henry Minsky wrote:
>>>>
>>>>>
>>>>>
>>>>> On 3/31/06, P T Withington <[EMAIL PROTECTED]> wrote: 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?
>>>>>
>>>>>
>>>>> Can we do that in IE JScript?
>>>>>
>>>>> 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]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Henry Minsky
>>>>> Software Architect
>>>>> [EMAIL PROTECTED]
>>>>>
>>>>
>>>> _______________________________________________
>>>> Laszlo-dev mailing list
>>>> [email protected]
>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>
>>
>
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
