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
>>
>>
>
