JavaScript Intermediary Sample

Question

I am creating a kind of intermediary library for my work. We create many applications, so I need something that can be easily adopted and changed for each application. I also want it to be easy enough to create “widgets” (due to the lack of a better term) and to easily remove them without worrying about breaking anything. Many of these applications that we make are also expanded by external developers creating applications or widgets for applications.

The way I stumbled upon a reseller template. I wrote 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 tho questions:

• How do you / work with DOM manipulation in this template using JavaScript? I don’t want developers to mess with the DOM outside of their widget.

• How to do / you need to handle AJAX requests. If you do anything at all? If you just offer an AJAX / JSONP call in the library ( Core in this example).

• My biggest question is, how do you actually interact with other widgets? I don’t need a tough couple (obviously), but I don’t understand how you will interact with other widgets. For example, let's say you have a text field, and on sending it sends it to the database. How can another widget call it a “timeline” widget, now that it has been submitted, and then update the timeline with 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 creating this a few days ago. I looked at how you implemented it, and here are some additional ideas for you.

The push system you created is very similar to the jQuery DOM event system, in which arbitrary events can be emitted and received. I use this system to develop decompressed widgets a little, but I found that I really want to, because in the end it pushes (events, emits anything) out of context - as in the listeners there is no idea, even within that what they wanted until they questioned the event.

Consider, for example, if every element of the user interface on a web page had a widget on your system. One page will easily have 30+. If each of them had to press the "downloaded" message, the remaining 29 should receive it. In addition, as you mentioned, third-party developers will develop this system. He then puts a burden on them to filter out messages that they do not want to receive.

The approach that I used in my last widget communication system is what I call the pubstring / substring approach (and, frankly, I'm sure someone else came up with this idea in front of me and some that sounds great). In principle, whenever a widget “pushes”, this push turns into a string that contains: the area (context), the type of widgets, the identifier of a particular widget, whatever it may be, and a specific message.

So, say, for example, a widget with ID 45, enter a “tweet list”, in the “user” area pushes the message “loaded”. Then the pub line will be displayed as follows: custom.tweet-list.45.loaded .

When subscriptions are placed, they are entered through a hash table, which may optionally contain values ​​for 4 attributes (you can easily add more than the scope / type / id / msg that I have). Then the listening will look like this:

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

Part of the listener of your framework can turn this hash table into a "substring", which will be a regular expression expressing the filters for which it represents:

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

This regular expression is saved as a compiled regular expression for some hidden array ...

__subscriptions.push(new RegExp(subString));

Then, whenever something has been clicked (i.e. posted), the structure basically goes through the __subscriptions array, disables the .test each saved substring (regex) and calls back for that substring, if appropriate.

Using this system, unlimited filtered listeners can be used, and listeners know that they receive notifications only for 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 regular expression is really just concatenation, the regular expression can also be included in the filter.

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

The beauty of this system is that you can still maintain your current interface “simplicity” and just check the row or 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 it was a long time ago, but I hope that it gave you some ideas.