Also, could you please point me to the code you've used (or copy it here). It would save me some time in the interim! I could imagine a useful library function could be built from it.
On Tue, Apr 22, 2008 at 6:51 PM, Michael Mahemoff <[EMAIL PROTECTED]> wrote: > Thanks Arne. Glad to know that option at least works in practice, even if > it's not very performant or reliable. I'll propose something for the spec if > no-one has a better solution. > > > On Tue, Apr 22, 2008 at 6:26 PM, Arne Roomann-Kurrik < > [EMAIL PROTECTED]> wrote: > > > 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 opensocial-api@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
