A couple more things:
1) Why "prefer" createElement to new lz[classname]? Even if LzNode is
really is a subclass of "class", why frown on the normal language means to
instantiate it?
2) The developer still needs to get at the class with perhaps bare
references like lz[classname], so that she can do pleasant things like
alter the class prototype at runtime.
A
On Sep 27, P T Withington wrote:
> [Revised after feedback on #laszlo]
>
> PROPOSAL
>
> 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 (`ConstructorMap`, which
> will be aliased as `lz`) which will map tag names to the class that implements
> the tag.
>
> As a part of this proposal, we will move LzNode.createElement and the other
> DOM-like API's from incubator/domapi.js to supported public interfaces and
> document createElement as the preferred way to dynamically instantiate a tag
> class.
>
> Finally, we will rename the <class> tag to <element> to more directly reflect
> that its purpose is to define a new LXZ DOM element (tag), not to define a
> Javascript 2 class. To define a Javascript 2 class in LZX use `<script> class
> foo { ... } </script>`.
>
> IMPACT
>
> User-defined elements whose name conflicts with already-defined global names
> will generate a warning at runtime and will not create a global definition
> (they will be entered in ConstructorMap/lz and work properly as tags, but you
> will not be able to use `new <tagname>` to instantiate them).
>
> Dynamically instantiating a DOM element using `new <tagname>(...)` will
> generate a deprecated warning at runtime in debug mode. This warning can be
> silenced by instead using `new lz.<tagname>(...)` or _preferably_
> `<parent>.createElement('<tagname>', ...)`. (The arguments to `new
> lz.<tagname>` and `createElement` 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.)
>
> Defining a new DOM element using `<class name="foo" ...` will generate a
> deprecated warning at compile time. This warning can be silenced by replacing
> `class` with `element`.
>
> BENEFITS
>
> This proposal addresses [Dynamic instantiation needs better
> API](http://www.openlaszlo.org/jira/browse/LPP-767) by legitimizing the use of
> LzNode.createElement as the preferred method of dynamically instantiating LZX
> elements. 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).
>
> SUMMARY
>
> I plan to implement all but the class->element transformation for Legal's PR4
> as the solution to LPP-2757, which is blocking several of the demos.
>
> Speak now, if you object.
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
