P T Withington wrote: > [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?
This sounds great! I propose we keep makeChild(), deprecate it, and add the DOM APIs appendChild, insertBefore, removeChild and replaceChild to LzNode. A few questions: Will there be a namespace one can use to instantiate a class directly if it doesn't need to live in the DOM, something like new LzUser.foo(...)? Or do all <class>es declared with a tag need to extend LzNode? Also, this sounds like an opportunity to allow package/namespace declarations for classes. It would be nice to have multiple instances of <button> with different namespaces for example. Will this be covered as well? -Max _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
