[Laszlo-dev] The concept of node.classname in 4.0.18

[Raju Bitter]

Tucker, I haven't tested that with a newer version of OL, since I'm  
very busy today. I'm not sure how other people use the searchSubnodes 
(attribute, value) method. I'd like to hear what other people think  
about it. Thanks!

On Nov 15, 2009, at 6:48 PM, P T Withington wrote:

> I see.
>
> It's annoying that searchSubnodes does not have an option to pass a  
> predicate, instead of just a property name and value.  Maybe we  
> should add another API to do that, say `searchSubnodesMatching`?   
> You would pass it a predicate function that would return true or  
> false.  Then you could say something like:
>
>  searchSubnodesMatching(function(node) { return node is lz.view; });
>
> I guess the closest you could get then is
>
>  searchSubnodes('constructor', lz.view);
>
> which would find all the nodes that _are_ <view>s.  (But not  
> anything that is a subclass of view. But, you'd have the same issue  
> testing for classname.)
>
> On 2009-11-15, at 11:41, Raju Bitter wrote:
>
>> Understood, the classes have a tagname field. But the instances  
>> don't have one, which doesn't give the ability to search the  
>> subviews/subnodes of a view for instances of a specific class. At  
>> least I don't know how to do that.
>>
>> Take this code:
>> <canvas debug="true">
>>   <view name="myView" width="100" height="100" bgcolor="red">
>>   </view>
>> </canvas>
>>
>> How could I search the canvas for a list of subviews based on the  
>> lz.view class? canvas.searchSubnodes("tagname", "view") doesn't  
>> work, since canvas.myView.tagname is undefined. Of course I could  
>> write my own method to do that, but I thought it's handy to be able  
>> to search the subnodes for specific instances of a class.
>>
>> On Nov 15, 2009, at 3:58 PM, P T Withington wrote:
>>
>>> All 4.0 classes have a `tagname` field.  Anywhere you used  
>>> `classname` in 3.x you should use `constructor.tagname` in 4.x.   
>>> We did this because LFC class names are different from the tag  
>>> they represent and we wanted a uniform API for both LZX and core  
>>> classes.  Using `constructor.tagname` will be forward compatible.
>>>
>>> On 2009-11-15, at 09:38, Raju Bitter wrote:
>>>
>>>> Thanks, Tucker. But that would only work for 4.1, I guess. 4.0.x  
>>>> didn't use the lz. namespace. I found a workaround using a bit  
>>>> more of initialization code.
>>>>
>>>> - Raju
>>>>
>>>> On Nov 15, 2009, at 2:49 PM, P T Withington wrote:
>>>>
>>>>> On 2009-11-15, at 06:19, Raju Bitter wrote:
>>>>>
>>>>>> In an old app OL 3.4 app I used the following code:
>>>>>>
>>>>>> var tabs = parent.searchSubnodes('classname', 'CustomTabs');
>>>>>>
>>>>>> But in 4.0.18 (Webtop) that doesn't work any more. What  
>>>>>> happened to the concept of being able to access the name of the  
>>>>>> class through nodeObject.classname? That worked in 3.3, and in  
>>>>>> 4.0.18 (Webtop) it returns "Object", which is not very helpful.  
>>>>>> By looking at the source code for LzNode I saw that it's  
>>>>>> possible to access the real classname through  
>>>>>> object.constructor.classname.
>>>>>>
>>>>>> Is that a bug, or a feature?
>>>>>
>>>>> You want to update your code to use 'tagname' instead of  
>>>>> 'classname'.  This was part of the attempt to make the LFC and  
>>>>> user classes uniformly accessible.  For all tags `t` in LZX:
>>>>>
>>>>> lz[t].tagname === t
>>>>>
>>>>>
>>>>
>>>
>>
>