My question has to do with the current (v2.3) implementation of WidgetManager.
Here's my scenario: I'm building a widget that needs to load up a custom info template. In my widget, I'm dispatching a DATA_CREATE_INFOWIDGET event much like the stock Locator widget does. Like in the Locator widget, I am including a callback function with that event.
Problem: when that info widget has finished loading, the wrong callback function is invoked! Instead of calling the callback function from my custom widget, it is calling the callback function in the Locator widget. NOTE: the Locator widget and my custom widget are both set to preload=true.
I did a little snooping and discovered that the WidgetManager stores the callback function in a private variable (m_infoWidgetCallback). Because of the order of configuration, the WidgetManager ends up overwriting my custom widget's callback function reference in m_infoWidgetCallback before it even has a chance to call it for my custom widget. So when the infoTemplate for my custom widget finally loads, WidgetManager actually erroneously invokes the Locator widget callback.
It seems that the WidgetManager singleton needs a more sophisticated method for storing and executing infoTemplate callback functions. In general practice I would recommend never storing transient data like this in a singleton property or private variable as it is sure to produce lots of hard to find timing-related bugs under load.
I am trying to avoid modifying the core viewer as much as possible but this seems like a case where I may be forced to. Am I missing something?
EDIT:
After looking a little further into the issue, I noticed some interesting constants in the AppEvent class: INFOWIDGET_REQUEST and INFOWIDGET_READY. However they are not currently used. Perhaps they will be used in the future to refactor away from the "request event + callback" approach to a "request event + response listener" approach? This would be safer and would keep the WidgetManager code simple.
