Patrón de mediador en JavaScript Preguntas

Question

Estoy creando una especie de biblioteca basada en el mediador de mi trabajo. Creamos muchas aplicaciones, por lo que quería algo que pueda tomarse y modificarse fácilmente por aplicación. También quiero que sea lo suficientemente fácil para crear "widgets" (por falta de un término mejor) y fácil de eliminar sin preocuparme por romper nada. Muchas de estas aplicaciones que hacemos también son extensibles por desarrolladores externos que crean aplicaciones o widgets para las aplicaciones.

Así es como me encontré con el patrón del mediador. Escribí algo que funciona algo como esto:

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

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

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

Tengo 3 preguntas Tho:

1. Cómo hacer/debe hacer frente a la manipulación DOM en este patrón con JavaScript? No quiero que los desarrolladores jueguen con el DOM fuera de su widget.

2. ¿Cómo/debo lidiar con las solicitudes de AJAX? ¿Deberías hacer algo en absoluto? En caso de que simplemente ofrezca una llamada AJAX/JSONP en la biblioteca (Core en este ejemplo).

3. Mi mayor pregunta, ¿cómo interactúas con otros widgets? No quiero tener pareja apretada (obviamente), pero no entiendo cómo interactuarías con otro widget. Por ejemplo, supongamos que tiene un cuadro de texto y al enviarlo lo envía a un DB. ¿Cómo puede otro widget, vamos a llamarlo el widget "línea de tiempo", ahora cuando se envió y luego actualizar la línea de tiempo con el texto del widget de cuadro de texto?

ACTUALIZACIÓN === ===

que terminó escribiendo esto:

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

Answer 1

Reproductores interactuar con los widgets: acabo de terminar la construcción de esto hace unos días. Revisé la forma en que lo implementó, y aquí hay algunas ideas adicionales para usted.

El sistema de inserción que ha creado es muy similar al sistema de eventos DOM de jQuery, mediante el cual se pueden emitir y recibir eventos arbitrarios. He estado usando ese sistema por un tiempo para desarrollar widgets desacoplados, pero lo encontré bastante deficiente porque en última instancia los "impulsos" (eventos, emisiones, lo que sea) están fuera de contexto, ya que los oyentes no tienen idea de si esto incluso está dentro del alcance de lo que querían hasta que interrogan el evento.

Considere por ejemplo si cada elemento de la interfaz de usuario en una página web era un widget en su sistema. Fácilmente habría más de 30 en una página. Si cada uno fuera a presionar un mensaje "cargado", los otros 29 tendrían que recibirlo. Además, como mencionó, los desarrolladores de terceros estarán desarrollando para este sistema. A continuación, les impone la carga de filtrar los mensajes que no desean recibir.

El enfoque que he tomado en mi último sistema de comunicación de widgets es lo que llamo un enfoque "pubstring"/"substring" (y para ser justos, estoy seguro de que alguien más ha presentado esta idea antes que yo y tiene un buen nombre para su sonido). Básicamente, cada vez que un widget "empuja", ese impulso se convierte en una cadena que contiene: el dominio (contexto), el tipo de widget, el ID específico del widget, cualquiera que sea, y el mensaje específico.

Digamos, por ejemplo, un artilugio con ID 45, escriba "tweet-list", en el reino "personalizado" presiona un mensaje "cargado". La cadena del pub se renderizaría a: custom.tweet-list.45.loaded.

Cuando las suscripciones se colocan, se ingresan a través de una tabla hash que puede contener opcionalmente valores para los 4 atributos (puede agregar fácilmente más además del dominio/tipo/id/msg que tengo). Escucha sería entonces como:

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

La parte oyente de su marco podría convertir esa tabla hash en un "subcadena", que sería una expresión regular la expresión de los filtros para la que representa:

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

Esa expresión regular se almacena como una expresión regular compilada en cierta gama oculto ...

__subscriptions.push(new RegExp(subString));

Luego, cada vez que se empuja algo (es decir. publicado), el marco básicamente recorre la matriz __subscriptions, activa un .test de cada subString almacenada (regex) y ejecuta la devolución de llamada para esa subString si coincide.

El uso de este sistema de oyentes filtrados ilimitadas se pueden aplicar y los oyentes saben que están recibiendo notificaciones sólo para los contextos en los que están interesados ​​en

Ejemplos:

.

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

Debido a que la expresión regular es en realidad una concatenación, regex también se puede incluir dentro del filtro.

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

Lo bueno de este sistema es que todavía se podía mantener su interfaz actual de "mantener cosa simple" y simplemente comprobar si una cadena o una tabla hash para argument[0]. En otras palabras ..

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

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

Sé que fue largo, pero espero que le haya dado algunas ideas.