I am using the below functions in current app to dynamically include JS, CSS
when in canvas view.
function JSinclude(script_filename) {
var html_doc = document.getElementsByTagName('head').item(0);
var js = document.createElement('script');
js.setAttribute('language', 'javascript');
js.setAttribute('type', 'text/javascript');
js.setAttribute('src', script_filename);
html_doc.appendChild(js);
return false;
}
function CSSinclude(script_filename)
{
var html_doc = document.getElementsByTagName('head').item(0);
var css = document.createElement('LINK');
css.setAttribute('REL', 'StyleSheet');
css.setAttribute('type', 'text/css');
css.setAttribute('media', 'screen');
css.setAttribute('HREF', script_filename);
html_doc.appendChild(css);
return false;
}
This has notable performance gain in profile view, when lots of apps compete
for bandwidth.
Thanks
~@@[EMAIL PROTECTED]
http://aakash-bapna.blogspot.com
> Date: Thu, 24 Apr 2008 10:08:16 +0100
> From: [EMAIL PROTECTED]
> To: [email protected]
> Subject: [OpenSocial] Re: Avoiding absolute URLs in JS/CSS includes
>
>
> FYI I've now posted this as a proposal to the spec group.
>
> On Tue, Apr 22, 2008 at 8:45 PM, Arne Roomann-Kurrik
> <[EMAIL PROTECTED]> wrote:
> > 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
> > >
> >
>
> >
_________________________________________________________________
Make i'm yours. Create a custom banner to support your cause.
http://im.live.com/Messenger/IM/Contribute/Default.aspx?source=TXT_TAGHM_MSN_Make_IM_Yours
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
