Question

I’m creating a sort of library based on the mediator for my work. We create lots of applications so I wanted something that can easily be taken and modified on a per app basis. I also want it to be easy enough to create “widgets” (for lack of a better term) and easy to remove them without worrying about breaking anything. Many of these apps we make are also extendable by outside developers making apps or widgets for the apps.

That’s how I came across the mediator pattern. I wrote up something that works something like this:

//Extend
Core.extend('widget',function(params){
  alert(params.message);
});

//Load it
Core.load('widget',{message:'Hello World'});

//Remove it
Core.remove('widget');

I have 3 questions tho:

1. How do/should you deal with DOM manipulation in this pattern with JavaScript? I don’t want developers messing with the DOM outside of their widget.

2. How do/should you deal with AJAX requests. Should you do anything at all? Should you just offer a AJAX/JSONP call in the library (Core in this example).

3. My biggest question, how do you actually interact with other widgets? I don’t want to tight couple (obviously), but I don’t get how you’d interact with another widget. For example, let’s say you have a text box and on submit it sends it to a DB. How can another widget, lets call it the “timeline” widget, now when it was submitted and then update the timeline with the text from the text box widget?

===UPDATE===

I ended up writing this:

http://oscargodson.github.com/Core.js/

Answer 1

Widgets interacting with widgets: I just finished building this a few days ago. I looked through the way you’ve implemented it, and here are some additional ideas for you.

The push system you’ve built is very similar to jQuery’s DOM event system, whereby arbitrary events can be emitted and received. I’ve been using that system for a bit do develop de-coupled widgets however I’ve found it quite wanting because ultimately “pushes” (events, emits, whatever) are out of context — as in listeners have no idea if this even is within the scope of what they wanted until they interrogate the event.

Consider for example if every UI element on a web page was a widget in your system. There would easily be 30+ on one page. If each one was to push a “loaded” message, the other 29 have to receive it. Furthermore, as you mentioned, 3rd party developers will be developing for this system. It then puts the burdens on them to filter out messages they don’t want to receive.

The approach I’ve taken in my latest widget-communication system is what I call a “pubstring”/”substring” approach (and to be fair I’m sure someone else has come up with this idea before me and has some cool sounding name for it). Basically, whenever a widget “pushes”, that push is turned into a string which contains: the realm (context), the widget’s type, the widget’s specific ID whatever it may be, and the specific message.

So say for example a widget with ID 45, type “tweet-list”, in realm “custom” pushes a message “loaded”. The pub string would then render to: custom.tweet-list.45.loaded.

When subscriptions are placed they are inputted via a hash table that can optionally contain values for the 4 attributes (you could easily add more besides the realm/type/id/msg I have). Listening would then be like:

listen({ realm: 'custom', type: 'whatever' }, f); // (where 'f' is a function)

The listener part of your framework could turn that hash table into a “substring” which would be a regular expression expressing the filters for which it represents:

custom\.whatever\.[^\.]+\.[^\.]+

That regex is stored as a compiled regular expression to some hidden array…

__subscriptions.push(new RegExp(subString));

Then whenever something was pushed (ie. published) the framework basically loops through the __subscriptions array, fires off a .test of each stored subString (regex) and executes the callback for that subString if matches.

Using this system unlimited filtered listeners can be applied and listeners know they’re receiving notifications for only the contexts they are interested in.

Examples:

// Listen for all messages by widget ID #99
listen({ id: 99 } ,f);

// Listen for all messages by widgets in realm clientB
listen({ realm: 'clientB' }, f);

// Listen for the data-received push of widgets whose type is tweet-list
listen({ type: 'tweet-list', message: 'data-received' }, f);

Because the regex is really just a concatenation, regex can be included within the filter too.

// Listen for any data- message
listen({ message: 'data-[^\.]+' }, f);

The beauty of this system is that you could still keep your current interface to “keep thing simple” and just test for a string or a hash table for argument[0]. In other words..

// This
listen('loaded', f);

// Could be equivalent to this on the backend:
listen({ message: 'loaded' }, f);

I know that was long but hope it gave you some ideas.