Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] Plugin registers but does not load.

re: ... if (listener.onModelChangedCSS) { <<< Mismatched change of function name here

Random thoughts... what we really could use here is some sort of api checker. I've been messing around with auto-writing unit tests to verify current API based on exploring the modules returned by requireJS. We can do the properties easily and maybe eventually do a better job on parameters using jsdoc or similar. This summer might be a good time to see what we can do around creating indexes that could be helpful for giving the editor limited type checking if not content assist. At the very least I'll continue with my unit test work as I really would like to have some confidence we're not busting API in Orion before we go 1.0. Busy with the release right now but will open a bug and CC you as I know you're into this sort of thing...

Inactive hide details for "John J. Barton" ---06/14/2011 12:15:15 AM---On 6/13/2011 8:59 PM, Simon Kaegi wrote: >"John J. Barton" ---06/14/2011 12:15:15 AM---On 6/13/2011 8:59 PM, Simon Kaegi wrote: >


From:

"John J. Barton" <johnjbarton@xxxxxxxxxxxxxxx>

To:

orion-dev@xxxxxxxxxxx

Date:

06/14/2011 12:15 AM

Subject:

Re: [orion-dev] Plugin registers but does not load.

Sent by:

orion-dev-bounces@xxxxxxxxxxx




On 6/13/2011 8:59 PM, Simon Kaegi wrote:
      John,

      If you're getting as far as messaging then I'd debug _publish(...) in plugin.js and _responseHandler(...) in pluginregistry.js

      After the initial load of a plugin the pluginregistry will cache any related service metadata
Just to say a bit more, the plugin install loads the plugin.html file, causing the plugin to run
provider.registerServiceProvider("orion.edit.listener", eventAdapterForCSS, {});
provider.connect();
This much can be debugged by a plugin author using console logging to verify that the calls happened during install.
      and then lazy load the plugin on other pages only when the service is accessed. If that's the sort of situation you're in I'd debug _load and _parseData in pluginregistry.js
Yes, this is much harder because the framework is pulling. I could look in localStorage and see the entry under 'orion.edit.listener' (now we are on the edit page, not the install).

The bug in my case was:

var modelListeners = serviceRegistry.getServiceReferences("orion.edit.listener");

for (var i=0; i<modelListeners.length; i++) {
serviceRegistry.getService(modelListeners[i]).then(function(listener) {
if (listener.onModelChangedCSS) { <<< Mismatched change of function name here
var eventAdapter = new EventAdapter(listener);
eventAdapter.initialize(listener);
}
});
}
I think I will make this an error, since the developer (me) intended to implement something on the listener. In fact I might have been better off without the test here: it replaces an exception with a silent fail.

(I'm also not completely sure about hacking the editor API this way, but that's another subject).

jjb

_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev


GIF image

GIF image


Back to the top