1 (edited by nearmedia 2010-08-16 21:47:14)

Topic: base path for widgets?

Hello,

In a browser when you want to develop a flash based solution, that is comprised of external xml and other resources, the embed tag allows you to set the relative path for all file loads.  This is done using the "base" attribute.

I would like to deploy a widget that uses a more complex directory structure and dependencies.  To do this, I can upload a file to the chumby.com site that when loaded, calls loadMovie() to load an externally located swf.  This seems to work nicely  -- (Thanks Duane!).  However, when this external file is loaded, it's relative directory is ... well not relative to it.

Is there a nifty trick in the flash player used to display chumby widgets that allows the setting of the "base" path of a widget?  Or any other trick, short of hard coding paths into the external resources (ouch), to achieve the goal of establishing a relative path?

Runtime sharing seems to be a non starter for widgets today based on this...

Thanks in advance for your response!

Re: base path for widgets?

I don't know of a way to set the base path of a movie from the movie itself - I suspect that's because it could be used to bypass crossdomain security.

Our current model has the developer upload a single movie, not a package of assets, plus movies can actually come from different places as we leverage CDNs, etc.

All of the widgets that I know of that load external resources do so with absolute paths.

Something to think about, though.

Re: base path for widgets?

Thanks Duane. 

It would definitely be beneficial.  By tethering Chumby online with the apps -- vs download apps with products like i* and android -- it seems that the Chumby store would be much more geared to leveraging online development styles.  Packages, assets and the like.

That being said, at the very least, I can "intelligently" hardcode all loaded paths by redirecting to an online swf and passing the path in a querystring parameter.  This will work for all mechanisms using load variations including xml and movies.  This will not work with runtime sharing.