javascript - Mediator Pattern in JavaScript Questions

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

ウィジェットとウィジェットの相互作用：数日前にこれを構築し終えたところです。私はあなたがそれを実装した方法を調べました、そしてここにあなたのためのいくつかの追加のアイデアがあります。

構築したプッシュシステムは、jQueryのDOMイベントシステムと非常によく似ており、任意のイベントを送受信できます。私はそのシステムを少し使用して分離ウィジェットを開発しましたが、最終的に「プッシュ」（イベント、放出など）がコンテキストから外れているため、非常に必要であることがわかりました-リスナーの場合、これが彼らがイベントを尋問するまで、彼らが望んでいた範囲内にさえあります。

たとえば、Webページ上のすべてのUI要素がシステム内のウィジェットであったかどうかを考えてみてください。1ページに30以上あるのは簡単です。それぞれが「ロードされた」メッセージをプッシュする場合、他の29人はそれを受信する必要があります。さらに、おっしゃるように、サードパーティの開発者がこのシステム用に開発します。次に、受信したくないメッセージを除外するために彼らに負担をかけます。

私が最新のウィジェット通信システムで採用したアプローチは、私が「pubstring」/「substring」アプローチと呼んでいるものです（そして公平を期すために、他の誰かが私の前にこのアイデアを思いつき、クールなサウンドを持っていると確信していますその名前）。基本的に、ウィジェットが「プッシュ」するたびに、そのプッシュは、レルム（コンテキスト）、ウィジェットのタイプ、ウィジェットの特定のID、および特定のメッセージを含む文字列に変換されます。

たとえば、ID 45のウィジェットで、「tweet-list」と入力すると、レルムで「custom」がメッセージ「loaded」をプッシュします。pub文字列は次のようにレンダリングされます custom.tweet-list.45.loaded。

サブスクリプションが配置されると、4つの属性の値をオプションで含めることができるハッシュテーブルを介して入力されます（私が持っているレルム/タイプ/ ID / msg以外に簡単に追加できます）。その場合、リスニングは次のようになります。

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

フレームワークのリスナー部分は、そのハッシュテーブルを「サブストリング」に変えることができます。これは、それが表すフィルターを表す正規表現になります。

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

その正規表現は、コンパイルされた正規表現としていくつかの隠し配列に格納されます...

__subscriptions.push(new RegExp(subString));

次に、何かがプッシュされた（つまり公開された）ときはいつでも、フレームワークは基本的に__subscriptions配列をループし、.test格納されている各subString（regex）を起動し、一致する場合はそのsubStringのコールバックを実行します。

このシステムを使用すると、無制限のフィルター処理されたリスナーを適用でき、リスナーは、関心のあるコンテキストについてのみ通知を受信して​​いることを認識します。

例：

// 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);

正規表現は実際には単なる連結であるため、正規表現をフィルターに含めることもできます。

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

このシステムの利点は、現在のインターフェイスを維持して「物事をシンプルに保つ」ことができ、文字列またはのハッシュテーブルをテストできることですargument[0]。言い換えると..

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

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

それが長かったことは知っていますが、それがあなたにいくつかのアイデアを与えてくれることを願っています。