I'm sure your right, but don't you agree that it is breaking the
general/kernel abstraction to have the general event handler directly
calling Sprite functions (since the kernel is potentially not even
written in Javascript, there really needs to be a wrapper around every
one of these, and in the case of sprites, the view is the natural
wrapper).
On 2008-05-07, at 15:18 EDT, André Bargull wrote:
If you're speaking about the swf7/swf8-kernel, things get pretty
hard to manage,
for example "LzSprite.prototype.setCursor(..)" registers the sprite
to its owner's "onmouseout"-event,
or another great example: the "LzMakeLoadSprite.createLoader()".
(The functions from LzMakeLoadSprite will be attached at runtime to
a LzSprite, when the sprite loads http-images. So, any reference to
"this" in LzMakeLoadSprite refers to a LzSprite. Yeah!).
Can I file a bug for you to do that? The most popular one I see
is the sprite scheduling checkPlayStatus2 on LzIdle. Instead it
should just use some runtime native timer, right?
On 2008-05-07, at 12:54 EDT, Max Carlson wrote:
>/ I agree - sprites shouldn't be allowed to send events directly
into />/ the system. Kernels should always use callbacks for
this... We've />/ been a bit sloppy with the swf8 kernel, but
dhtml and swf9 _should_ />/ use callbacks exclusively.
/>/
/>/ P T Withington wrote:
/>>/ Actually, thinking about it, the Sprite, being in the kernel,
has />>/ no business trying to use a generic service like events.
Each />>/ sprite implementation needs to use its own kernel
services directly />>/ to do any eventing. I think that in most
cases the sprite is just />>/ registering a timeout event, which
should be simple to do.
/>>/ On 2008-05-07, at 11:49 EDT, P T Withington wrote:
/>>>/ It really turns out that LzDelegate and LzEvent want their /
>>>/ context's to be LzMiniNode's (because they want to look at /
>>>/ __LZdeleted, __LZdeferDelegates, and _events). If all
context's />>>/ were LzMiniNodes (or LzEventable, as proposed
yesterday), we could />>>/ also implement automatic tracking of
events and delegates so they />>>/ won't leak when nodes are
destroyed (eliminating the burden on />>>/ every LZX class doing
this for themselves).
/>>>/
/>>>/ I tried to enforce this, but run into trouble because
Sprite's />>>/ want to register themselves as delegates, but they
are not mini />>>/ nodes.
/>>>/
/>>>/ One thought: I create a superclass LzSimpleDelegate and /
>>>/ LzSimpleEvent that work with any object and don't participate
in />>>/ the node protocol.
/>>>/
/>>>/ Any better ideas?
/>/
/>/ -- />/ Regards,
/>/ Max Carlson
/>/ OpenLaszlo.org/
