[Laszlo-dev] For Review: Change 20080428-Philip-4. Summary: Fix tree_example in dhtml

[P T Withington]

That would be a fine solution too, but then you need to fix the  
receiver to do:

   if (lz[tagname] is Function) {
     return new lz[tagname]
   } else if ($debug) {
     Debug.error("Invalid tag %s", tagname);
   }

Hm.  That is such a common idiom, perhaps there should be a LFC helper  
function `makeTag` or something.

On 2008-04-29, at 09:11 EDT, André Bargull wrote:

> When you take a look at the 3.3.x sources for basetree, you can see  
> that this is most likely only a doc-bug:
> The doc says: "Returns class to use for instantiating replicated  
> tree children", but effectively it returns a classname. And in  
> previous releases, a classname was like the tagname, because we put  
> them all happily in the global namespace.
> Therefore, I think you should update the doc and return the tagname  
> instead of a class. (Users may have overridden that method and in  
> their apps, they return a classname/tagname (almost the same in old  
> releases, see above), but with that change their apps will break.)
>
>> var c = this.getChildClass();
>> if (c != null) {
>>    new global[c](this, args, null, true);
>> }
>> <!--- Returns class to use for instantiating replicated tree  
>> children.
>>      If tree is leaf, return null, since we don't care to instantiate
>>      any more subtrees. Override this method to instantiate different
>>      classes. -->
>> <method name="getChildClass">
>>    if (this.isleaf) return null;
>>    return this.classname;
>> </method>
>
>> Approved!
>>
>> On 2008-04-28, at 20:37 EDT, Philip Romanik wrote:
>>
>> >/ Change 20080428-Philip-4 by Philip at Philip-DC <http://www.openlaszlo.org/mailman/listinfo/laszlo-dev 
>> > on 2008-04-28 20:25:04  />/ EDT
>> />/    in /cygdrive/f/laszlo/svn/src/svn/openlaszlo/trunk
>> />/    for http://svn.openlaszlo.org/openlaszlo/trunk
>> />/
>> />/ Summary: Fix tree_example in dhtml
>> />/
>> />/ New Features:
>> />/
>> />/ Bugs Fixed: LPP-5748
>> />/
>> />/ Technical Reviewer: ptw
>> />/ QA Reviewer: (pending)
>> />/ Doc Reviewer: (pending)
>> />/
>> />/ Documentation:
>> />/
>> />/ Release Notes:
>> />/
>> />/ Details:
>> />/ basetree.lzx was trying to create objects using the string name  
>> of  />/ the class. I also changed the calls to setVisible() to  
>> remove the  />/ deprecated warnings.
>> />/
>> />/ This is Tucker's definitive explanation of the issue:
>> />/
>> />/ The correct fix is to fix getChildClass, which currently says:
>> />/
>> />/         <method name="getChildClass">
>> />/             if (this.isleaf) return null;
>> />/             return this.constructor.classname;
>> />/         </method>
>> />/
>> />/ I guess the confusion is that it implies it returns a class,  
>> but it  />/ is actually returning a class _name_ (a string).
>> />/
>> />/ There are two choices of how to fix it.  If you need a tag  
>> name,  />/ because you are going to look it up in the `lz` module  
>> (as is done  />/ in say, baselist#addItem) you want:
>> />/
>> />/   this.constructor.tagname
>> />/
>> />/ If you look this up in lz:
>> />/
>> />/   lz[this.constructor.tagname]
>> />/
>> />/ you will get the constructor for the class that implements that  
>> tag.
>> />/
>> />/ But, if you just want the constructor directly, just say:
>> />/
>> />/   this.constructor
>> />/
>> />/ It should always be the case that:
>> />/
>> />/   lz[this.constructor.tagname] === this.constuctor
>> />/
>> />/ There's a bunch of confusion that has been introduced because  
>> we  />/ have made classnames non-global, and they don't necessarily  
>> match  />/ the name of the tag they implement.  (They never did for  
>> the LFC, we  />/ are now just uniform for all classes that  
>> implement tags).
>> />/
>> />/ I guess the confusion is increased because to the LZX  
>> programmer,  />/ when they say:
>> />/
>> />/   <class name="foo" ...
>> />/
>> />/ they think they have created a class named `foo`, but really  
>> they  />/ have created a (Javascript) class with an anonymous name  
>> that  />/ implements the tag named `foo`.  The mapping from tag  
>> name to  />/ implementation class is through the `lz` table.   
>> Perhaps we should  />/ rename the Javascript `classname` property  
>> to  />/ `implementationclassname` or perhaps get rid of it  
>> altogether, as it  />/ seems to only be a source of confusion...   
>> I'll leave it to you if  />/ you want to file an improvement  
>> request to that effect.
>> />/
>> />/
>> />/
>> />/ Tests:
>> />/ tree example runs in dhtml:
>> />/ http://localhost:8080/trunk/examples/components/tree_example.lzx?lzr=dhtml
>> />/
>> />/ Files:
>> />/ M      lps/components/base/basetree.lzx
>> />/
>> />/ Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080428-Philip-4.tar
>> />
>