Sure, check out http://lamerankings.googlecode.com/svn/tags/1.0/lamerankings.xml - the code in that gadget includes a bunch of files and calls a callback when they're all loaded.
~Arne On Tue, Apr 22, 2008 at 11:13 AM, Michael Mahemoff <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
