[Resent with a From: address the mailing list will accept] Currently, when you define a new class using the <class> tag, it defines a global var of the same name. We propose to no longer define the global. Rather, the created class will be stored in a table which will map tag names to the class that implements the tag. LzNode.makeChild will be changed to use this table, so code that uses the makeChild interface to create instances dynamically will still work.
The incompatible change is that a tag `foo` defined using `<class name="foo" ...` will no longer be able to be instantiated dynamically by `new foo(...)`. Such code should be replaced by `<parent>.makeChild(...)`. (The arguments to `new foo` and `makeChild` are similar but different -- this is not a recipe on how to rewrite one to the other, just a note that you will need to rewrite.) This proposal goes part way to addressing [Dynamic instantiation needs better API](http://www.openlaszlo.org/jira/browse/LPP-767). As a part of this proposal, we will make LzNode.makeChild a public function and document it as the preferred way to dynamically instantiate a tag class. This will be a change to [Creating objects from script](http://www.openlaszlo.org/lps-latest/docs/guide/ introductory-classes.html#d0e13841) and [Instantiating classes through script](http://www.openlaszlo.org/lps-latest/docs/guide/class- inheritance.html#d0e17585) -- which probably should be just one entry rather than two. This proposal will also fix the long-standing issue that the built-in tags are implemented by classes whose name does not correspond to the tag name. Under this proposal, all dynamic instantiation of tag classes will be by tag name, so that issue goes away. This proposal will also fix [Defining a user class named `top` breaks DHTML in Safari](http://www.openlaszlo.org/jira/browse/LPP-2757) by removing tag classes from the global namespace. It would give us the opportunity to unwind the kludge used to fix [Support with <grid> and <menubar> issues](http://www.openlaszlo.org/jira/browse/LPP-775). Finally, we _could_ take this opportunity to define a more DOM-like interface for LZX node creation by defining LzNode.createElement, and moving the data node DOM API's (appendChild, insertBefore, removeChild, replaceChild) to LzNode, and preferring that interface rather than makeChild. But perhaps that is going to far? Comments? _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
