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 -~----------~----~----~----~------~----~------~--~---
