concept easyXDM in category javascript
This is an excerpt from Manning's book Third-Party JavaScript.
The ExternalInterface class also exposes a public call method that can be used to access JavaScript properties and methods from the host page. You can use that method to notify the host page about new messages coming their way. The example in listing 5.7 shows an implementation of the onMessage function that notifies an external JavaScript method on the host page. We took this example from the source code of a popular cross-domain messaging library called easyXDM. We’ll cover easyXDM shortly in section 5.3.
This ActionScript implementation of a cross-domain channel isn’t the most fun program to write, so usually developers—including the authors of this book—reuse an existing open source implementation that was written and tested by somebody else. If you’re interested in the specifics of the ActionScript implementation, we encourage you to check out the source code of easyXDM. It’s available on GitHub: https://github.com/oyvindkinsey/easyXDM/. But before we dive into easyXDM, let’s talk about a couple of gotchas that often bite developers who decide to rely on Flash for their cross-domain communication needs.
In chapter 2, you learned how to ship external JavaScript libraries with your third-party application by placing them on your global namespace object, and easyXDM is no different. Like jQuery, easyXDM provides a noconflict mode through a special method named noConflict. The following code snippet demonstrates using this method to place a copy of the easyXDM library in the Stork namespace:
You’ll notice that this method takes a single formal parameter—a string representing the name of your namespace object on the global window object. This is so that easyXDM can locate itself via the global window object when using the same-origin transport. You’re not likely to use this transport as a third-party application (because you’re working with different origins), but you should specify this parameter to be safe.
Additionally, the easyXDM library must be present on both consumer (parent) and provider (iframe) pages. This means you’ll need to load the library in both locations, but you don’t need any additional configuration; easyXDM will automatically detect which context it’s in.
Another important thing is that you don’t need to manually create any iframes with easyXDM—it’ll handle that work for you. All you need is to do is to create a new instance of either easyXDM.Socket for simple messages or easyXDM.Rpc for configuring a JSON-RPC interface between the consumer and provider. Both the Socket and Rpc constructor functions accept a variety of different options, described in table 5.3.
Table 5.3. easyXDM options
Option
Description
Consumer or provider
remote Path to the provider. easyXDM will create and load an iframe with the value of remote as a URL. Consumer onReady A function that will be called after the communication has been established. Both local Path to the name.html on the consumer’s domain, used by the NameTransport. Both swf Path to the easyxdm.swf file, used by the FlashTransport. Both swfNoThrottle Set to true if you want your iframe/swf object to be placed visibly in order to avoid throttle in newer versions of Flash. Both swfContainer A DOM element where easyXDM should place the swf object. Both lazy Set to true if you want to delay the iframe creation until the first use of easyXDM.Socket. Consumer container A DOM element where easyXDM should place the iframe element. By default, it’s body. Consumer props A JavaScript object representing the properties you want your iframe to have. Consumer remoteHelper Path to the name.html on the provider’s domain, used by the NameTransport. Consumer hash Set to true if you want to use hash instead of the query string to pass initial parameters to the iframe (helps with caching). Consumer acl A string or an array of domains. Set this if you want only specific domains to consume the provider. Provider