Broadway v2 proposal from @pksunkara

proposal.md

broadway.js (module)

var App = function () {
  // Constructor
  this.on('app::*') {
    this.plugins.forEach(function (e) {
      if (e[eventname]) {
        e[eventname]();
      }
      // We can have all types here, (Ex: async callback, sync callback, data passing)
    }
  }
}

App.prototype.use = function (plugin, options) {
  this.plugins.push(plugin);
}

App.prototype.init = function () {
  this.emit('app::init');
}

app.js

var broadway = require("broadway");

var app = new broadway.App();

// Passes the second argument to `helloworld.attach`.
app.use(require("./plugins/helloworld"), { "delimiter": "!" } );

app.init(function (err) {
  if (err) {
    console.log(err);
  }
});

app.hello("world");

app.emit('app::name');

app.hello("world");

plugins/helloworld.js

exports.init = function () {
  this.hello = function (world) {
    console.log("Hello "+ options.name || world + options.delimiter || ".");
  }
}

exports.name = function () {
  options.name = 'pavan'
}

Output

$ node app.js
Hello world!
Hello pavan!

Usage in flatiron

var path = require('path');
var broadway = require("broadway");

var app = new broadway.App();

fs.readdir(__dirname + '/node_modules/flatiron-*', function (err, files) {
  files.forEach(function (e) {
    app.use(require(e));
  });
});

Now the flatiron components such as director, union, resourceful uses app.emit to call events on which the plugins run things

@jesusabdullah proposed a better solution for this without changing the core api

https://github.com/nodejitsu/blog/pull/11

I am in agreement with @jesusabdullah here: this seems like sugar syntax wrapping the EventEmitter2 interface exposed by broadway.App instances.

There also seems to be a fundamental flaw as to how we would implement: "all types here, (Ex: async callback, sync callback, data passing)". Since event handlers are by definition sync, and can have variable data arguments, it is impossible to determine which handlers are sync and which are async.

I think this could be better addressed by the proposal I've outlined here: https://gist.github.com/1812647