ryanguill / emit Goto Github PK

this will required a change to how the listeners are stored internally, instead of a once flag, store the number of times and then check and decrement when the listener is fired.

once() will become an alias for many(eventName, listener, 1, async)

Create tests for all api methods. Need to decide mxunit or testbox. Suggestions welcome.

This would allow you to listen on a.* which would fire on a.b or a.c.

• matches zero or one word separated by periods, # matches one zero or more words.

addEventListener("#", listener) would listen on all events.

Need to consider if this means we need to pass event name into the listener by default...

Externalize adding a pipeline as an event listener on complete, allow users to pass a pipeline object into addEventListener directly if thats what they want to do. This would allow users to use a pipeline as a listener or to just run them directly.

Emit events "newListener" and "removeListener"s by default.

example:

    on(["user.create", "user.delete"], function(){});

I expect that the argument name "Event" is a common thing that users will be trying to pass in - plus eventName is more descriptive.

Need to add clear use cases to the readme. There are several though.

Notes from IRC discussion:

DanSkaggs: RyanGuill: can you give a real example of what emit would be used to do? Having trouble meshing CFML with async ways of doing things
RyanGuill: understandable - its hard to think about async and cf
RyanGuill: the two biggest uses I have (although there are others) is to do easy async - I need to do this and dont care to get any result out of it, and to allow loosly coupled extension points from a service
RyanGuill: so you can say for example that your userService is going to emit an event called user.create any time a new user is created, and then other services can register a listener to that event and get notified anytime that happens
DanSkaggs: ah, so sort of a lightweight message queue server thing, but residing in CFML rather than ActiveMQ or similar?
RyanGuill: you dont have to know at the time that you write the userService what all that will be used for
RyanGuill: yeah, very much like that
DanSkaggs: gotcha…with you now
RyanGuill: in fact im using it right now in between cf and rabbitmq, I use emit for lighter weight stuff that I dont need load balanced, and rabbitmq for the heavier duty stuff
DanSkaggs: I wasn’t getting that idea from reading the README on the GitHub page
RyanGuill: yeah, I can see that. I need to get a good elevator pitch going, and maybe a good example in there
RyanGuill: it makes a lot more sense if you have used eventemitter in node or flex events
DanSkaggs: we’ve been talking about setting up a JMS server here. I’ll have the other guys take a look at emit and see if that can be an intermediary step
DanSkaggs: yeah, never did much Flex and am just getting into NodeJS
RyanGuill: yeah so I was having a conversation with my boss yesterday and my delineation between those things right now is: if its okay that the async happens on the same server (from a resources perspective) and you dont need load balancing, emit is a good way to go, otherwise use an actual message queue
RyanGuill: to me, even without the event stuff, its nice to be able to say emit.async(funciton(){//some code});
RyanGuill: way easier than using cfthread

Write some example applications describing the use cases.

this.mappings["/tests"] = expandPath("./");

issues with closures means that you need to have the ability to have emit call a method on an instance directly.

I think what would be necessary is to have a way to take
on('eventName', serviceInstance, 'methodName') and detect that arrangement and call it appropriately around here https://github.com/ryanguill/emit/blob/master/lib/emit.cfc#L308