Vows for events other then 'success' or 'error'

[seebees]

My understanding is that vows will listen for success and error events on a topics returned EventEmitter. It will forward the arguments from a success event to vows with one argument (?) and error events to vows with two arguments (?).

But what about events other then success or error? I don't mind writing the code, but I didn't want to do a bunch of stuff and then have someone tell me I'm crazy.

What I'm proposing is to use the event name to group the vows. Like this:

"A topic that emits many events" : {
  topic: function () {
    return new CrazyEmitter();
  },
  "end" : {
    "will be clean" : function(){}
  },
  "request" : {
    "will emit the new request" : function () {},
    "will set my class with a cached element" : function () {}
  }
}

Would output something like:

A topic that emits many events
    ✓ on request: will emit the new request
    ✓ on request: will set my class with a cached element
    ✓ on end: will be clean

Clearly the legacy behavior would be supported, so vows that do not match an event would be treated as they are currently, but you could clearly call out 'success' or 'error' if you like.

Incidentally, this would also take care of issue #76, and it might help make the callback(err, result) vs .emit( business a little clearer. If you me wanted to go really crazy I could even have a special "event" callback so you could mix returning an EventEmitter and this.callback. But maybe that's just crazy talk.

Just so we are all clear, the only way I see to do this is to cheat. I would hook EventEmitter.prototype.emit. I'm pretty sure there is a special place in hell reserved just for me, but in the meantime I would have fewer topics and more vows.

[fnl]

I am having exactly this problem: I am writing a client on top of HTTP request that behaves just as the HTTP ClientRequest, so the callback receives the single response emitter. Now, vows doesn't like this at all... Just to get it to work somehow, I had to define my test functions as:

function (res, junk) {
  // test something on res...
}

I don't understand why the "callback(err, res)" pattern is hard-coded into vows functionality? Even worse, if your callbacks don't work exactly with that pattern, vows tries to take the response and parse it to JSON (yet another issue, raised by someone else)... So if your callbacks work differently, vows might start reporting errors about circular references, instead of anything even remotely sensible.

[cloudhead]

I like this idea.

[seebees]

all right. I'll put something together.

[seebees]

I have a two questions. How should I know that the sub object is an event and not another context? e.g. that "end" from my example above is an event and not simply a sub topic? I see a few options.

1. Because "end" and "request" do not have a topic, therefore they are events.
2. We wait until topic.on('success') fires and search through emitted events and route the results.
3. Some kind of syntax, e.g. "[end]" that means these vows are for an event.

Inside this question is a routing question. vows uses topic.addvow() as a wrapper for topic.on('success', magic) should I extend this magic to allow for an ordering of events?

topic.addvow = function(vow, event) {
  this.on(event, magic);
}

I'm not always a fan of arbitrary syntax but, backwards compatibility... I lean a little towards something like:

"A topic that emits many events" : {
  topic: function () {
    return new CrazyEmitter();
  },
  "[request]" : {
    "will emit the new request" : function () {},
    "will set my class with a cached element" : function () {},
    "[end]" : {
      "will be clean" : function(){}
    }
  }
}

This would dictate that end should fire after request. It would also mean that I am not waiting for success at all. This means that Array.prototype.unshift.apply(ctx.topics, arguments) moves to addVow, not sure how yet, but I need to get rid of the .on('success')

[seebees]

Ok, I don't think that the work is done. There needs to be a few more tests written, but I wanted someone to look at it and comment.