On Sep 27, 2006, at 8:32 AM, Max Carlson wrote:
> 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
I think this is great as well, and another +1 on the DOM APIs on LzNode.
Might we slightly avoid the need to introduce namespaces by allowing
local classes? We'd eventually want namespaces, but local classes
would be nice either way.
<class name="foo">
<class name="bar"/>
</class>
I suppose you'd need to have multiple tag-to-class tables stored as
static class attrs, with global class declarations being added to
LzNode's table.
jim
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
