[Dynapi-Chat] Serious Event model bug

[Laszlo T. <las...@po...>]

After spending the better part of a day trying to track down a bug I though
I introduced into my code, when migrating from a November 2000 version
DynAPI script to the current 2.55a version, I realized that something more
serious was causing my agony.

After searching through the lists and bug reports, I came across what I
think is the earliest mention of this problem. Bug number 425789 reported on
May 20, 2001.

Basically any widget that does not inherit directly from DynLayer can not be
used more than once on a single page, unless you only want one EventListener
for the whole lot (very unlikely).

If you try to create multiple EventListeners (i.e. one for each widget of a
class not derived directly from DynLayers), only the last EventListener
assigned to one of this second generation widgets will fire. And it will
fire on all widgets that are instances of the same class.

I have been mainly working with the ButtonImage class derived from DynImage,
but I believe this will affect List, PushPanel and any other second
generation widget.

Seeing that this problem has been around for some time, I imagine the
solution will require a lot of work. A temporary solution would be to
rewrite any second generation widget to inherit directly from DynLayer and
including any other inherited functions from it's former parent. I realize
this is redundant and counter to OOP, but at least we would have complex
widgets that work. There is no point in streamlining the core for
performance if the core is broken. This would be a relatively simple fix.
And could be reversed easily once the event model is fixed. This would also
not require changes in code implementing these widgets, thus have little
effect on users other than performance due to redundancy.

The other solution is to fix the problem in the event model. This will take
longer, but should be top priority. The whole purpose of DynAPI is to have
complex widgets, and a common API. For simple widgets anyone can create
simple JavaScript that has less overhead than DynAPI. Therefore this bug
undermines the purpose of DynAPI.

We did not have this bug in 2.0. What has changed so drastically since 2.0
in the event model or in other parts of the core that introduced this bug.
Any idea?


Laszlo