If SMASH was a part of YUI...

Hey,


Yahoo User Interface is one of the best written javascript frameworks till date. However, I still have not seen support for mash ups as a native component. With the YUI Event library, I see that including a utility to create a mashup would be simple, and would gel well with the programming model.
In this post, I analyze the various tweaks that would be required to the event model that would permit a user to use events from mashup modules of different domain seamlessly. The protocol standard could be anything, but I take SMASH as a reference model. This technique ensures that both the mashup creator and the component creator continue to use the YUI event model for communication, even though the domain (and hence, the javascript namespace) are different.
YUI could provide two libraries, and a configuration file

1. Container page that is to be embedded in the page that holds the components ( as iFrames from different domains), called the masher
2. Individual components, displayed inside iFrames, called mashees.
3. A security descriptor file that would describe and govern the interaction between different components.
   

The main masher page would include script or tags to create the required iFrames to display the component mashees. While creating a component, the communication channel name (a static HTML page at the masher server) would also be passed along. The library would also create an event queue to receive and send events.
The mashees would include YUI files indicating them to be mashup components. As soon as the page loads, the mashup library would kick in and create another hidden iFrame inside the component to allow communication from the component mashee to the masher. This hidden iFrame would be a static HTML file with javascript functions to add events to the YUI event queue. Similarly, the YUI component in the component would also poll for changes in the URL to receive events.
The only difference between the regular event model and this technique is that instead of directly calling the subscriber, the event would be written to component URL. Since we also have a YUI stub at the component mashee, the events would be read, and this is the place where the target listeners would be invoked. Hence, to the user, it would still look be an event subscribe and publish model .
Lastly, the security policy file at the container masher would determine if the events are to be propagated to the child elements or not. I am currently writing these, so watch out this space for updates.