683486 - EventEmitter API in pageMod context improvements

Status: RESOLVED DUPLICATE of bug 653629

(Add-on SDK Graveyard :: General, defect)

Description

[Matěj Cepl]

I have described the problem more in my blogpost http://matej.ceplovi.cz/blog/2011/08/what-have-the-eventemitter-framework-ever-done-for-us/. Executive summary is that solution of the problem in bug 635748 (avoiding ugly long Windows-like switch/if-then-else constructs for handling messages between content scripts and the main Add-on script) was never achieved. Now instead of huge switch (possibly hidden somewhere in another function; see for example https://fedorahosted.org/bugzilla-triage-scripts/browser/lib/main.js?rev=711aa30074cca61adc99afd958bf0f11d5d68ea5 and function messageHandler), I have to have directly in the PageMod constructor long list of worker.on handlers, e.g.:

  worker.port.on('GetURL', function (command) {
    libbz.getURL(command.url,
      function(stuff) {
        worker.port.emit(command.backMessage,
          stuff);
   });
  });

which is IMHO even worse (if possible) than original switch statement.

I would much prefer if I was to able to have something like this:

var page = pageMod.PageMod({ ... });

page.on("GetURL", function (url, backMessage) {
  libbz.getURL(url, function (requestedData) {
     worker.port.emit(backMessage, requestedData);
  });
});

so that I could have these event handlers as a separate units with appropriate JavaDocs (or other kind of comments, let's not rehash THAT flamewar here) etc. I believe it would be much cleaner and easier to understand.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Yes, I totally agree, this API is not as refined as it could be!

We discussed this in bug 649629 a few months ago and ended up filing bug 653629 on it.

My proposal is that we do a superset of what you suggest, namely:

  let mod = PageMod({
    ...
    port: {
      onSomething: function(...) { ... }
    }
  });
  mod.port.on("SomethingElse", function(...) { ... });