On 2006-09-27, at 13:07 EDT, David Temkin wrote:
> On Sep 27, 2006, at 5:32 AM, P T Withington wrote:
>> 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.)
>
> While I understand why this is appealing from an implementation
> standpoint, I have to say that this solution appears to be a step
> in the wrong direction. It breaks an organizing principle that
> makes LZX (somewhat) comprehensible -- namely, that tags and
> classes are one and the same.
>
> Being able to do "new foo(...)" is pretty important, especially as
> we try to attract JS developers. And not all tag-defined classes
> are visual, so they don't necessarily have a visual parent.
I think this is a canard. Because for any class that is defined by
the <class> tag, you can't _just_ say `new foo(...)`. The arguments
to the new call are both arcane and cast in stone (they are:
parentNode, initialAttributes, childrenSpec,
whetherToInstantiateAsynchronously). [That is unless you are talking
about instantiating a data node, in which case there is a different
set of arcane arguments.]
I think we fool ourselves by using the tag <class> when we really
mean <tag> or <element>. If we want people to be able to specify
straight classes in LZX, we could add a tag for that, but I think the
correct tag for that is <script> class foo { ... } </script>.
The current <class> tag really can only be used to create a new DOM
element type, associated with a particular tag, and hence I believe
it should only be instantiable using the DOM interface createElement.
>> 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.
>
> Now this I like! For exactly the reason stated above -- clarity of
> mapping between tags and classes.
>
> Is there any way to work this such that we could do, say "new lz.foo
> (xxx)" where lz is a hypothetical namespace for built-in classes?
> (Then how do you declare the class/tag? more work, more work)
I believe Javascript-level namespaces are orthogonal to the issue I
am trying to address here. The _only_ issue I am trying to address
here is that our implementation that allows LZX code to create new
DOM tags/elements can clobber or collide with global variables. This
is a bug in our implementation. It is also a bug in our
implementation that we don't have a comprehensible interface to
dynamically instantiate DOM tag/elements (using new on the tag
implementation class with its arcane arguments is not comprehensible).
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
