[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 <[EMAIL PROTECTED]>
To: Bret Simister <[EMAIL PROTECTED]>, Chris
Pettitt
<[EMAIL PROTECTED]>, Dave Nault
<[EMAIL PROTECTED]>, Elliot Winard
<[EMAIL PROTECTED]>, Scott Evans
<[EMAIL PROTECTED]>, John Sundman
<[EMAIL PROTECTED]>, lchouanard
<[EMAIL PROTECTED]>, Mark Davis
<[EMAIL PROTECTED]>, Pablo Kang
<[EMAIL PROTECTED]>, qa <[EMAIL PROTECTED]>, Sarah
Allen <[EMAIL PROTECTED]>, Yossie Silverman
<[EMAIL PROTECTED]>, David Temkin
<[EMAIL PROTECTED]>
Change 51366 by [EMAIL PROTECTED] 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
---=---===-------
