Hi Michael, I've been using the "on-demand Javascript/CSS" option since I like to host my gadgets out of SVN, so branching and tagging (which wind up changing the location of the source files) causes problems for hard coded paths. Sadly, there doesn't seem to be a better option than parsing the parent string out of the iframe and using that to calculate a base path for the gadget.
These sorts of functions would make a good addition to the gadget spec. Could you propose a modification in this group: http://groups.google.com/group/opensocial-and-gadgets-spec/topics ? Thanks, ~Arne On Tue, Apr 22, 2008 at 5:22 AM, Michael Mahemoff <[EMAIL PROTECTED]> wrote: > Hello, > > I'm developing some gadgets that include some custom JS and CSS library > files. Being content-type html, they would usually require hard-coded URLs, > no relative paths as they're served from gmodules etc as opposed to my own > server. However, they're intended for distribution, so I want to avoid > hard-coding the entire URL in <script> and css <link> tags. What's the best > option here? I've considered the following options, but none are ideal: > > - Generate the gadget spec from a server-side script or pre-compiler > (which inspects the current path). But I want to keep it simple and avoid > those kinds of dependencies. > - Use content-type=URL. But I want to use "html" and in any event, it's > going to be better supported that way. > - Avoid including CSS/JS files - keep it all in one file. This is the way > gadgets are typically envisioned to work. But there is common code and I > want to avoid duplication. > - Use "on-demand Javascript/CSS", ie dynamically include the JS/CSS by > programmatically generating a script tag (or remotely fetching and eval'ing > in the case of JS). This would be slower, but workable. It does raises > another question: is there an API call to discover the source URL for the > current gadget? (You could do it in a hacky way by parsing the iframe URL, > but it would be unreliable and container-dependent. I think there should be > such a "gadget reflection" type function available. > - Is there a better option? > > It would be good if there was a way to <require> a script, which could > then optionally be cached by the container. > > > > -- OpenSocial IRC - irc://irc.freenode.net/opensocial --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenSocial Application Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/opensocial-api?hl=en -~----------~----~----~----~------~----~------~--~---
