I have two relevant data points as an end-user of Laszlo:
1. When I first started using Laszlo, I went looking through the docs
to try and find a DOM-like "createElement" API, couldn't find it, and
after looking through the replication manager code I concluded that
one didn't exist. I eventually discovered the new Foo(parent, attrs)
mechanism on Oliver's blog. I found that API to be unlike anything I
had seen before.
In other words, I think I missed the documented API because it didn't
look like what I was expecting.
2. My most common mistake when using Laszlo: forgetting
inherits="View" when creating a new <class>.
I'm assuming the element tag will default to inheriting from View?
If so, then the proposed changes make a lot of sense to me. (And
they're backward compatible w/deprecation, which is terrific.)
My 2c,
-Neil
On Sep 27, 2006, at 11:17 PM, P T Withington wrote:
> I don't think you read the whole revised proposal.
>
> I responded to your earlier comments on this by proposing to continue
> supporting `new <tagname>` (when the tagname does not collide with a
> browser global), with a deprecation warning telling you to use `new
> lz.<tagname>` instead.
>
> Personally, I feel that `createElement('<tagname>')` will be more
> intuitive to the newbie, if they are coming from DHTML, and that `new
> lz.<tagname>` is more advanced, but both will be supported.
>
> I do think that we confuse people by using <class> to define new DOM
> element types. <class> is not like class: it defines a class that
> _must_ be a subclass of LZNode, it must obey the node protocols, and
> it is meant to be a DOM element. I think if we rename it to
> <element> it will clarify that the classes that implement elements
> are more specific than a general Javascript class.
>
> On 2006-09-27, at 21:45 EDT, David Temkin wrote:
>
>> We've absolutely got to keep our eye on learnability, and this
>> proposal, I think, is problematic in that regard. We're all hoping
>> for a lot of new developers once Legals is released. And that
>> requires paying attention to the conceptual simplicity of the system.
>>
>> I've always been bothered by the view/LzView disjunction. This
>> proposal fixes that, but is a step backward in another way.
>>
>> From a newbie point of view, "class" and "<class>" are pretty much
>> the same thing.
>>
>> They're objects that can be instantiated, have methods, inherit
>> from other classes, etc. It is just plain confusing to have to
>> learn about the differences between the two, and put them in
>> different mental categories. Yes, you can get more features by
>> declaring a class in LZX vs. in script (attributes, constraints),
>> but that's a-OK. It's still a class in the ordinary sense of the
>> term -- that is the fact.
>>
>> To the extent that these two notions of class deviate, they need to
>> be brought closer together, not separated out into two very similar
>> but differently named concepts.
>>
>> As for the proximate issue (instantiation), why can't we have the
>> "new" operator first search for the class name in the
>> "ConstructorMap" and then, if there is no entry there, look for a
>> global of that name? That does lead to the issue of how you
>> actually would instantiate a browser-native window (masked by an
>> entry in lz), but that I think is of lesser importance in this
>> context.
>>
>> Later, we could transition to something like
>>
>> <class name="lz:window"....>
>>
>> which might be instantiated procedurally as
>>
>> new lz.window(xxx)
>>
>> And lz could be set up as the default namespace in an LZX document.
>>
>> - D.
>>
>>
>>
>>
>>
>> On Sep 27, 2006, at 4:37 PM, 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
>>
>
>
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
