看起来这样又好又全面，但是其实还有一个露点：如果我给对象定义一个本地事件，既想要观察者直接调用，又可以被订阅者间接访问到，怎么办？这就是我为什么说要串联在一起：你推送或者桥接本地事件到消息组去吧。需要些更多代码？很有可能——但是总比你把观察对象传递给所有观察者，一直紧耦合下去的情况好。然后，我们可以很好地继续以下两点...
3.) 选择性的“提交”本地事件到总线
最开始我几乎只用观察者模式来在JavaScript中触发事件。这是我们一次又一次遇到的模式，但更流行的客户端辅助库行为方式根本上来说是混合中介者的，给我们提供了就像它们是观察者模式的API。我最初写postal.js的时候，开始走进“为所有事物搭中介”的阶段。在我写的原型与构造函数中，分布各处的发布与订阅的调用并不罕见。当我从这个改变中自然的解耦受益时，非基础的代码开始似乎充满了相关于基础的部分。构造函数到处都要带上一个通道，订阅被当作新实例的一部分被创建，原型方法直接发布一个数值到总线（甚至本地的订阅者都不能直接的而必须监听总线以获得信息）。将这些明显关于总线的东西纳入app的这些部分，开始像是代码的味道。代码的“叙述”似乎总是被打断，如“噢，将这个向所有订阅者发布出去”，“等等！等等！监听这个通道那个事情。好，现在继续吧”。我的测试忽然开始需要依赖总线来做低层次的单元测试。而这感觉有点不对劲。
钟摆摆动的指向了中间，我认识到我应该保持一个“本地API”，并且在需要的时候通过一个中介者为应用扩展其可以触及的数据。 例如，我的backbone视图与模型，仍然用普通的Backbome.Events行为来给本地观察者发送事件(就是说，模型的事件被它相应的视图所观察)。当app的其它部分需要知道模型的变化时，我开始通过这些行将本地事件与总线桥接起来：
var SomeModel = Backbone.Model.extend({ initialize: function() { this.on("change:superImportantField", function(model, value) { postal.publish({ channel : "someChannel", topic : "omg.super.important.field.changed", data : { muyImportante: value, otherFoo: "otherBar" } }); }); } });
重要的是要认识到，当有可能透明的推送事件到消息总线时，本地事件和消息必须被认为是分开的合约——至少概念上如此。换句话说，你要能够修改“内部的/本地的”事件而不破坏消息合约。这是要在脑海中记住的重要事实——否则你就是为紧耦合提供了一个新的途径，在一个方法上走反了！
所以理所当然，上述的模型是可以在没有消息总线的情况下被测试。而且如果我移去桥接在本地事件与总线之间的逻辑，我的视图与模型依然工作得毫无不畅。但是，这可是七行的例子（尽管格式化了）。 仅仅桥接四个事件就需要几乎三十行的代码。
噢，你怎样才能二者兼顾呢—— 在适合直接观察者时本地通知，同时使涉及事件可以扩展，以便你的对象不必给所有对象都发送一圈——不需要代码膨胀。通知怎样才能很少的代码又有更多的味道呢？
4.)在你的构架中隐藏样板
这并不是说上面的例子中的代码 —— 将事件接入总线 —— 的语法或概念是错误的（假设你接受本地和远程/桥接事件的概念）。然而，这是一个很好的体现在代码基础之上培养良好习惯的作用的例子。有时我们会听到类似“代码实在太多了”的抱怨（特别是当 LOC 作为代码质量的唯一判定者时）。 当这种情况下，我表示赞同。 它是一个可怕的样板。 下面是我在桥接 Backbone 对象的本地事件到 postal.js 时使用的模式：
// the logic to wire up publications and subscriptions // exists in our custom MsgBackboneView constructor var SomeView = MsgBackboneView.extend({ className : "i-am-classy", // bridging local events triggered by this view publications: { // This is the more common 'shorthand' syntax // The key name is the name of the event. The // value is "channel topic" in postal. So this // means the bridgeTooFar event will get // published to postal on the "comm" channel // using a topic of "thats.far.enough". By default // the 1st argument passed to the event callback // will become the message payload. bridgeTooFar : "comm thats.far.enough", // However, the longhand approach works like this: // The key is still the event name that will be bridged. // The value is an object that provides a channel name, // a topic (which can be a string or a function returning // a string), and an optional data function that returns // the object that should be the message payload. bridgeBurned: { channel : "comm", topic : "match.lit", data : function() { return { id: this.get("id"), foo: 'bar' }; } }, // This is how we subscribe to the bus and invoke // local methods to handle incoming messages subscriptions: { // The key is the name of the method to invoke. // The value is the "channel topic" to subscribe to. // So this will subscribe to the "hotChannel" channel // with a topic binding of "start.burning.*", and any // message arriving gets routed to the "burnItWithFire" // method on the view. burnItWithFire : "hotChannel start.burning.*" }, burnItWithFire: function(data, envelope) { // do stuff with message data and/or envelope } // other wire-up, etc. });