On Tue, May 3, 2011 at 2:48 PM, Ed Venaglia <[email protected]>wrote:
> Hello all.
>
> I am encountering problems in implementing the flash transport in our
> container. Our container is based the shindig 2.0.0 tag with a few,
> very-minor, changes.
>
> Can someone help me resolve the problems I am encountering, so we can use
> the flash transport in our container?
>
> -Ed Venaglia-
> Senior Software Engineer
> Jive Software, Inc.
>
> -----
>
> Changes so far:
> Added flash.transport.js and xpc.swf to the shindig-feature
> jar in our local build.
> Modified rpc.js to always return the gadgets.rpctx.flash
> object from getTransport()
> Modified the feature.xml to include flash.transport.js for
> the gadget and the container
> Built a servlet to serve the xpc.swf file and added its path
> to rpc.commSwf in the container configuration file.
>
> What works:
> The transport being selected returns "flash" when getCode()
> is invoked on it
> The servlet is being called and is delivering the xpc.swf file upon request
> I can see the <object/> being added to the DOM of both the gadget iframe
> and on the container page
>
> What is broken: (in flash.transport.js)
> pendingHandshakes accumulates data and never gets consumed
> flushHandshakes() gets called before relayHandle is set, but
> not after
>
> Where I am stumped:
> I added window.setTimeout(flushHandshakes, 0); to the end of
> relayLoader() immediately after relayHandle is set
> flushHandshakes() still fails because
> relayHandle contains a DOM element, which does not have a 'setup' method
> I am unable to determine the purpose of the relayHandle
> variable
> It is assigned the value of a DOM element:
> <object/> [line 91]
> The property 'setup' is accessed on it [line
> 128]
> A dynamic property is accessed on it [line
> 137]
>
relayHandle is the magic of how the whole thing works. It's the handle to
the DOM object containing the SWF, which allows script access to its
exported methods.
Within the SWF's implementation (Main.as), you'll see
ExternalInterface.addCallback('methodId', function...) calls. These are
exposed as DOMElement['methodId'] calls that can be made "into" the SWF.
That it doesn't appear to have a setup method suggests to me that for some
reason your Flash<->JS bridge isn't working right. Some of that is black
magic to me, but the core requirement should just be that you embed as per
the <object> code in flash.transport.js with allowScriptAccess="always" set.
I usually test in Chrome and verify in IE. Both work for me.
Other nasty gotchas:
* Ensure the SWF is created with the proper &origin= param.
* Ensure the SWF that's embedded has the same root URL. Flash's security
model accounts for both the domain of the SWF and the domain of the page in
which it's embedded.
>
> Environments:
> Ubuntu 10.04 LTS, Firefox 3.6.17, Flash version 10.2.159.1
> Windows XP SP3, IE7.0.5730.13, Flash version 10.1.102.64
> Mac OS X 10.6.7, Safari 5.0.5, Flash version 10.1.102.64
>
>
