View Full Version : EventProvider vs. Observable (choose one?)

8 Dec 2006, 10:26 AM
I've had numerous instances where there is a conflict between YUI's EventProvider and YUI-EXT's Observable when I'm extending a YUI-EXT class. They both are "mixed in" to a class and have similar method names (e.g. fireEvent) which causes conflicts.

Jack, do you plan to play nice and upgrade YUI-EXT to follow the EventProvider model or will you suggest that we all ignore the EventProvider object and use yours to avoid conflicts? I realize you introduced this pattern before YUI but since they have adopted it and your library is based off of theirs it follows that you might be open to "augmenting" your code? (pun intended)

Thanks, and keep up the great work!


8 Dec 2006, 10:36 AM
Well Jack shouldn't have to 'play nice' with YUI since his event model preceded the YUI stuff and his I believe provides more functionality than YUI. Yahoo was smart enough to not name their objects to conflict with yui-ext, which they released after yui-ext.

Also, given that the object names are different, how can you be getting conflicts regardless of whether the event names are the same. That's not to say that if you're using both events, it may be confusing as to which one applies at any given time, but that's another story :) Please provide examples.

There are a number of people here using both libraries combined and have not reported this type of issue.

9 Dec 2006, 9:02 AM
Their decision to use the name "fireEvent" was unfortunate. However, I can't adopt their class because it doesn't provide delayedListener or purgeListeners and still only passes the first param object if FLAT is the CustomEvent type.

I would recommend using Observable instead of EventProvider not only because of the additional functionality, but also because it is so important to yui-ext that it will never be removed. EventProvider is only used in one spot that I know of in YUI (TabView).

9 Dec 2006, 9:32 AM
tryanDLS, although the object names are different YUI chose to name one of their methods "fireEvent". I am extending the DefaultDataModel object and I want to use the YUI EventProvider methodology of creating and firing custom events which, when used, mixes in a method named "fireEvent". I will have a conflict as DefaultDataModel already mixes in the Observable method named "fireEvent".

Jack, it doesn't seem like many others are experiencing this problem yet, but if they do you may be able to solve it by simply extending the EventProvider object to include your delayedListener and purgeListeners if the EventProvider would support them. Then, at least you would have parity between the calls made.

In the meantime I'll reluctantly change our code to use Observable rather than EventProvider ;-).


9 Dec 2006, 10:53 AM
Extending it to support those two would have been ideal. The real problem lies with the way the events are fired. Observable uses fireDirect and EventProvider uses FLAT.

On a side note, why would you be reluctant to use a class that has been around for a while and is implemented and working in many components vs a class that is new and is only being used in one component? To me it seems like a no-brainer.

9 Dec 2006, 1:48 PM
There was one good idea they had in EventProvider though that I didn't think of. That was lazy initializing the CustomEvent objects. The latest Observable in SVN has this functionality.