And that is why you shouldn't start an email 5 days before you finish it. Key point is I like the eventEmitter idea better.
Ignore everything I wrote before the two examples as I was young and nieve ;) On Tue, Dec 6, 2011 at 5:09 PM, Gord Tanner <[email protected]> wrote: > You can probably see where I got the inspiration from then ;) > > The API is basically the same as the EventEmitter except that the > EventEmitter from node allows you to new up other event emitters, where our > module is a singleton instance. > > I wouldn't know where to store the instance of the eventEmitter if we did > use the node pattern. Ideally we shouldn't need to import anything into > the window object (other than the device APIs) so that would rule out > making window.PhoneGap an instance of an event emitter. > > I personally like the lack of flexibility of having one central place > where all events are triggered and acted upon. > > Basically we ether end up with: > > -------- > PhoneGap.on("foo", func); > > PRO: > - allow multiple instances of EventEmiters > - can be used as a base class. > - Syntax that is close to what we have now. > > CON: > - forces storage of shared eventEmitters in the global space > > -------- > or: > -------- > var event = require("phonegap/event"); > event.on("foo", func); > > PRO: > - can be used in a decoupled fashion in any module > - no requirement of hanging shared emitters off of the window object > - all events are funneled by the same emitter. > > CON: > - only one event emitter to rule them all. > - all events are funneled by the same emitter. > --------- > > > I personally am liking the EventEmitter Approach a lot more as I would > like to have the ability to separate some of the events by instance: > > var phonegap = require("phonegap"); > > phonegap.on("nativeready", func); > > var network = require("phonegap/network"); > network.on("ready", func); > > var device = require("phonegap/device"); > device.on("ready", func); > > Thoughts? > > Gord > > > On Thu, Dec 1, 2011 at 5:12 PM, Patrick Mueller <[email protected]> wrote: > >> On Thu, Dec 1, 2011 at 16:48, Gord Tanner <[email protected]> wrote: >> > Please see reference branch here: >> > https://github.com/gtanner/callback-js/tree/event >> > >> > One of the issues with Channel's in a module based system is that it is >> > awkward to keep track to a central repository of channel objects. >> >> I guess I'm a n00b. I don't know what a Channel is. >> >> > I coded up a quick prototype using an event module. This gives us the >> > ability to trigger and sync on events by just using a string (rather >> than >> > an instance created before hand). It cleans up some of the code and >> doesn't >> > require the pre-construction of all the channels before hand. >> >> Your API is actually fairly close the nodejs's "events" module: >> >> http://nodejs.org/docs/v0.6.3/api/events.html >> >> Close, but different. In addition to the shape being different, the >> receiver/subject of the functions/methods is different - in your case, >> the subject is a global string identifying the event itself; in node's >> case, events are objects which are instances of EventEmitter, with >> method names closely corresponding to some of your function names. >> >> So, here's an alternative strategy: >> >> - implement a compatible nodejs "events" module >> >> - implement a separate module which has a list of the global events we >> think we'll need, with the ability to add more, somehow. Those global >> events would, of course, be instances of our compatible EventEmitter >> class. >> >> The only thing I wonder about is "implementing a compatible version of >> a nodejs module". You'd think that would be a kosher thing to do, at >> least if you did it in a clean-room fashion. But, who knows these >> days. >> >> -- >> Patrick Mueller >> http://muellerware.org >> > >
