[Laszlo-dev] The meaning of <handler> and <method> in <library>
David Temkin
temkin at laszlosystems.com
Thu Jun 21 08:23:29 PDT 2007
[moving thread to laszlo-dev]
I think what I said on this issue may have gotten lost in translation.
I'm not sure it's a bad thing from a language point of view that
<library> allows you to add methods and handers to the canvas, and I
certainly don't think it "breaks the XML structure" -- no more than
<state> breaks it. Given how <library> is defined, I would expect it
to put methods/handlers/whatever into its parent. That's how we
defined it.
>>>> it totally breaks my mental
>>>> model which was that everything declared in a library was exactly
>>>> like declaring directly in the canvas tag. I'll bet other
>>>> developers
>>>> have this mental model also. Since the coding pattern is often
>>>> that
>>>> you code merrily along in a <canvas> tag than re- factor into
>>>> libary
>>>> files by simply cutting parts into various files.
I agree with this viewpoint. The model implied by <library>/<include>
is essentially one of textual inclusion with a little bit of add-on
smarts.
That isn't to say that this could be changed if there's a very good
reason to do so (simpler implementation, more room for optimization).
But I do think the construct as now defined, with the implied
behavior of attaching its child elements to the element that embeds
the <library> element (canvas), makes sense. Exceptions to this
reduce learnability.
- D.
> On Jun 20, 2007, at 8:41 PM, Sarah Allen wrote:
>
>> including internal-dev, rather than the list of developers who
>> happen to
>> listen to P4 reviews... (new folks, please read Tucker's note below
>> first, and only if you typically definite canvas methods or events in
>> libraries)
>>
>> The heart of the question, is what does the <library> tag mean?
>> It is
>> not a node, like every other tag in LZX, and gets magically compiled
>> away. Everything else that is inside the library tag is conceptually
>> under the <canvas> tag, hence the confusion.
>>
>> My question regarding OL4 was that if this is a side-effect of the
>> compiler in 3.4, might that have changed in OL4 when there was a
>> substantial refactor of the whole system? If it is working in
>> OL4, it
>> is pretty dangerous and weird to support something that you all
>> believe
>> is inappropriate and plan to break in the future (although I wouldn't
>> recommend breaking it right now just for the sake of language
>> purity.)
>>
>> Sarah
>>
>> p.s. if you all think its a really bad thing to declare methods and
>> handlers in libraries, we can stop doing it. I just want to be
>> clear on
>> what works and what doesn't and why.
>>
>> On Wed, Jun 20, 2007 at 8:15 PM, P T Withington wrote:
>>
>>> [Adding Platform-Team, perhaps our chief language architect would
>>> like
>>> to weigh in on this. Oh, wait, he quit. Bueller? Anybody?]
>>>
>>> On 2007-06-20, at 17:59 EDT, Sarah Allen wrote:
>>>
>>>> so... for the record:
>>>>
>>>> You can, in the main file that starts with <canvas>, have handlers
>>>> and methods
>>>> You cannot, in a library, define handlers and methods, but you
>>>> could
>>>> declare
>>>> <method event="oninit" reference="canvas">
>>>> (although perhaps this isn't the right syntax, because I thought
>>>> Elliot mentioned to me that events were deprecated in OL4)
>>>
>>> The new syntax is:
>>>
>>> <handler name="oninit">
>>>
>>> If this tag appears as an immediate child of the canvas, the
>>> reference
>>> defaults to the canvas (it defaults to the parent of the handler
>>> tag).
>>> If you want to write a handler in some tag other than the canvas but
>>> want it to handle the canvas's `oninit` event, you need to
>>> explicitly
>>> supply the reference:
>>>
>>> <handler name="oninit" reference="canvas">
>>>
>>> That's my understanding of the language. Clearly we define the
>>> language and if we want a different definition we can make it so.
>>> But, my opinion from both an XML point of view and from the compiler
>>> implementor point of view is that it would be a bad idea to say
>>> `handler` in a `library` implicitly refers to the canvas.
>>>
>>> A separate question is whether you should be able to have a handler
>>> tag directly inside a library or not. Right now the compiler only
>>> expects to have (subclasses of) node at the top level, e.g., classes
>>> or instances and scripts.
>>>
>>>> and in a library, I could define
>>>> <script>
>>>> canvas.myMethod = function ...
>>>> </script>
>>>
>>> This is true, but again with my language/compiler hat on we really
>>> don't want to support that. If you want to support this in Flash 9,
>>> it will mean we cannot take advantage of their fast class
>>> implementation. To have the ability to add methods to a class at
>>> run
>>> time, you have to declare the class to be dynamic, which makes it
>>> run
>>> in slow mode.
>>>
>>> This is what I was trying to get at below with my discussion of
>>> 'compilation units'.
>>>
>>>> is this true?
>>>
>>> Yes. With the caveats I have mentioned.
>>>
>>>> is this only a limitation with binary libraries?
>>>
>>> It is a limitation of libraries. As David said, it was really
>>> only an
>>> accident that it worked in libraries. If you made your library a
>>> dynamic library it would not work. And it does not work in a binary
>>> library. It could be made to work. Making it work will limit the
>>> optimizations we can make in the future.
>>>
>>>> is this also a limitation for OL4?
>>>
>>> It has nothing to do with OL3 vs. 4. It has to do with our
>>> libraries
>>> becoming real libraries (being treated as separate compilation
>>> units)
>>> rather than straight includes.
>>>
>>>> We can probably live with this, but it totally breaks my mental
>>>> model which was that everything declared in a library was exactly
>>>> like declaring directly in the canvas tag. I'll bet other
>>>> developers
>>>> have this mental model also. Since the coding pattern is often
>>>> that
>>>> you code merrily along in a <canvas> tag than re- factor into
>>>> libary
>>>> files by simply cutting parts into various files. The problem is
>>>> made worse by the fact that it happens to work just fine in LZX
>>>> (3.4) today.
>>>
>>> If libraries were straight textual includes, I could see that. But
>>> they aren't (despite using the tag `include` to refer to them: it
>>> would have been better if we used the tag `require` because that is
>>> what the compiler really does -- it keeps track of whether or
>>> not it
>>> has already loaded a library and only loads it once).
>>>
>>>> Confused,
>>>> Sarah
>>>>
>>>> On Wed, Jun 20, 2007 at 2:23 PM, P T Withington wrote:
>>>>
>>>>> I thought what David was getting at was that syntactically, it
>>>>> looks like you are trying to add the methods/handlers to the
>>>>> library, not the canvas. It breaks our nice XML language model.
>>>>>
>>>>> We allow you to put methods and handlers on the canvas, but they
>>>>> should appear in the canvas tag, not in some inner tag (like
>>>>> library).
>>>>>
>>>>> From the compiler-guy-who-has-to-implement-this point of view, we
>>>>> treat a library as our unit of compilation, and it is generally
>>>>> considered a bad thing in language design to permit one
>>>>> compilation
>>>>> unit to diddle with the internals of another. (It's permitted in
>>>>> C++, which everyone now agrees is a mistake, because it means
>>>>> technically only the linker can optimize C++.)
>>>>>
>>>>> As I explained to Eliot, you are allowed in our language to add
>>>>> handlers for events on other objects, so you can add a handler to
>>>>> the canvas, but you'll need to tell the compiler the `reference`
>>>>> for the handler (and put the handler declaration in a place that
>>>>> allows it).
>>>>>
>>>>> In any case, I didn't do anything about this issue, because of
>>>>> what
>>>>> David said, and because we worked around the places where it was
>>>>> used (unfortunately, I don't recall the details).
>>>>>
>>>>> On 2007-06-20, at 16:40 EDT, Sarah Allen wrote:
>>>>>
>>>>>> The case Elliot ran into may not be right, but I do believe
>>>>>> that
>>>>>> it is a feature not a bug that we can define a method on the
>>>>>> canvas. I replied to the thread below with:
>>>>>>
>>>>>> what do you mean by side-effect? the lzo compilation bug? or the
>>>>>> fact that we can declare methods on the canvas? (if the latter,
>>>>>> you may have never planned it that way, but we have been
>>>>>> expecting
>>>>>> and relying on that behavior for years, and if you want I can
>>>>>> let
>>>>>> you know why I think it is a good thing)
>>>>>>
>>>>>> and I thought you had gone ahead and fixed binary libraries so
>>>>>> that the behavior was supported. I sure hope it is supported in
>>>>>> Legals, even if it was not a feature you ever intended to support
>>>>>> at the beginning of time. Certainly defining an onint on the
>>>>>> canvas is required...
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 20, 2007 at 9:20 AM, P T Withington wrote:
>>>>>>
>>>>>>> Here's my understanding (elaborating on this message from David
>>>>>>>
>>>>>>>> On 2007-03-07, at 10:48 EST, David Temkin wrote:
>>>>>>>>> That seems like a side-effect or bug to me. I would not
>>>>>>>>> expect
>>>>>>>>> it to work that way.
>>>>>>>>>
>>>>>>>>> On Mar 7, 2007, at 6:03 AM, Sarah Allen wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Here's an example of a library that defines a method on the
>>>>>>>>>> canvas:
>>>>>>>>>>
>>>>>>>>>> <library>
>>>>>>>>>> <method name="foo"/>
>>>>>>>>>> </library>
>>>>>>>
>>>>>>> ):
>>>>>>>
>>>>>>> It is an accident of the implementation of the compiler that
>>>>>>> top-
>>>>>>> level <method> (<handler>, etc.) tags in a <library> have been
>>>>>>> getting attached to the canvas. This should be an error,
>>>>>>> because
>>>>>>> libraries are not nodes, so don't have methods (handlers,
>>>>>>> etc.).
>>>>>>> To change that would mean an architectural change to the
>>>>>>> language. The bug here is that the compiler (binary or normal)
>>>>>>> does not complain when it stumbles across these illegal tags
>>>>>>> in a
>>>>>>> library.
>>>>>>>
>>>>>>> In the particular case that Eliot has run across, it seems what
>>>>>>> you are trying to do is wait until you know that the dialog
>>>>>>> handler class is defined before you tell the dialog manager
>>>>>>> about
>>>>>>> it. This can easily be handled by a <script> tag following the
>>>>>>> class definition. Script tags are defined to be evaluated in
>>>>>>> lexical order.
>>>>>>>
>>>>>>> On 2007-06-20, at 11:30 EDT, Sarah Allen wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> really? I thought Tucker had made it so there could be
>>>>>>>> methods
>>>>>>>> on the canvas? I certainly hope we can declare a canvas
>>>>>>>> "oninit"
>>>>>>>> handler...
>>>>>>>>
>>>>>>>> On Wed, Jun 20, 2007 at 7:50 AM, Elliot Winard wrote:
>>>>>>>>
>>>>>>>>> My bad.
>>>>>>>>>
>>>>>>>>> The problem here was the way the dialogs registered themselves
>>>>>>>>> with the gDialogManager.
>>>>>>>>> Dialogs are not instantiated until they are needed and are
>>>>>>>>> then
>>>>>>>>> reused.
>>>>>>>>> The LZX files included oninit handlers that registered
>>>>>>>>> themselves for canvas oninit events. Binary libraries can
>>>>>>>>> have
>>>>>>>>> class definitions and instances but can not include handlers
>>>>>>>>> outside of class definitions and instances.
>>>>>>>>>
>>>>>>>>> The fix was to hard-code the names of default classes to use
>>>>>>>>> for Confirm and Alert dialogs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jun 20, 2007 at 9:43 AM, Sarah Allen wrote:
>>>>>>>>>
>>>>>>>>>> In a changeset like this it would be good to note the spirit
>>>>>>>>>> of the bug fix. What was the underlying problem and how was
>>>>>>>>>> it addressed? I know I could look at the diffs, but a
>>>>>>>>>> summary
>>>>>>>>>> would be nice.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Sarah
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------- Begin forwarded message --------
>>>>>>>>>> Subject: PERFORCE change 51366 for review
>>>>>>>>>> Date: 6/19/2007 4:10:33 PM
>>>>>>>>>> From: Elliot Winard <ewinard at laszlosystems.com>
>>>>>>>>>> To: Bret Simister <bsimister at laszlosystems.com>, Chris
>>>>>>>>>> Pettitt
>>>>>>>>>> <cpettitt at laszlosystems.com>, Dave Nault
>>>>>>>>>> <dnault at laszlosystems.com>, Elliot Winard
>>>>>>>>>> <ewinard at laszlosystems.com>, Scott Evans
>>>>>>>>>> <gse at laszlosystems.com>, John Sundman
>>>>>>>>>> <jsundman at laszlosystems.com>, lchouanard
>>>>>>>>>> <lchouanard at laszlosystems.com>, Mark Davis
>>>>>>>>>> <mdavis at laszlosystems.com>, Pablo Kang
>>>>>>>>>> <pkang at laszlosystems.com>, qa <qa at laszlosystems.com>, Sarah
>>>>>>>>>> Allen <sallen at laszlosystems.com>, Yossie Silverman
>>>>>>>>>> <yossie at laszlosystems.com>, David Temkin
>>>>>>>>>> <temkin at laszlosystems.com>
>>>>>>>>>>
>>>>>>>>>> Change 51366 by ewinard at EWINARD-T60-3.4 on 2007/06/19
>>>>>>>>>> 16:06:02
>>>>>>>>>>
>>>>>>>>>> BUG FIXED::EM-1685::Cannot delete Folders in http://emma:
>>>>>>>>>> 8080/ diamond-lzmail-sql-dist-lzmail-silver-latest/ 1241
>>>>>>>>>> BUG FIXED::EM-1684::Unable to delete the folder with delete
>>>>>>>>>> folder button or right click option
>>>>>>>>>> BUG FIXED::EM-1686::Once enter rich text into the message
>>>>>>>>>> body, the user will not be able to switch back to the plain
>>>>>>>>>> text
>>>>>>>>>> BUG FIXED::EM-1683::Anything with a confirmation pop up
>>>>>>>>>> fails. All error and warning pop ups are not occurring. in
>>>>>>>>>> http:// emma: 8080/diamond-lzmail-sql-dist-lzmail-silver-
>>>>>>>>>> latest/ 1241
>>>>>>>>>> BUG FIXED::EM-1671::Can not sign out if editing a contact
>>>>>>>>>> BUG FIXED::EM-1670::Can not sign out if a modified
>>>>>>>>>> preferences view is open
>>>>>>>>>> BUG FIXED::EM-1669::Can not log out if you have a compose
>>>>>>>>>> view open
>>>>>>>>>> BUG FIXED::EM-1672::Can not sign out while a message is
>>>>>>>>>> being
>>>>>>>>>> sent
>>>>>>>>>> BUG FIXED::EM-1670::Can not sign out if a modified
>>>>>>>>>> preferences view is open
>>>>>>>>>> BUG FIXED::EM-1690::Delete contact button cannot be used to
>>>>>>>>>> remove the selected contact from list.
>>>>>>>>>> REVIEWER::pablo
>>>>>>>>>>
>>>>>>>>>> Affected files ...
>>>>>>>>>>
>>>>>>>>>> ... //depot/apps/diamond/client/components/window/dialog/
>>>>>>>>>> alertdialog.lzx#5 edit
>>>>>>>>>> ... //depot/apps/diamond/client/components/window/dialog/
>>>>>>>>>> confirmdialog.lzx#5 edit
>>>>>>>>>> ... //depot/apps/diamond/client/framework/utils/
>>>>>>>>>> gdialogman.lzx#10 edit
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---=---===-------
>>>>>>>>> Elliot Winard
>>>>>>>>> Sr. Software Engineer
>>>>>>>>> Laszlo Studios
>>>>>>>>> ---=---===-------
>>
>> _______________________________________
>>
>> Internal-Dev mailing list
>> Internal-Dev at laszlosystems.com
>> https://hedwig.laszlosystems.com/mailman/listinfo/internal-dev
>>
>> To search the dev list: http://lists.laszlosystems.com/intranet/
>> finddev.cgi
>
More information about the Laszlo-dev
mailing list