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.
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.
> 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.
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 <api.kur...@google.com> wrote:
> 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.
> On Tue, Apr 22, 2008 at 5:22 AM, Michael Mahemoff <mich...@mahemoff.com> > 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.
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 <mich...@mahemoff.com> 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 < > api.kur...@google.com> 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.
> > On Tue, Apr 22, 2008 at 5:22 AM, Michael Mahemoff <mich...@mahemoff.com> > > 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.
> 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 <mich...@mahemoff.com> > 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 < > > api.kur...@google.com> 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.
> > > On Tue, Apr 22, 2008 at 5:22 AM, Michael Mahemoff < > > > mich...@mahemoff.com> 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.
> On Tue, Apr 22, 2008 at 11:13 AM, Michael Mahemoff <mich...@mahemoff.com> > 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 <mich...@mahemoff.com> > 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 > <api.kur...@google.com> 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.
> > > > On Tue, Apr 22, 2008 at 5:22 AM, Michael Mahemoff > <mich...@mahemoff.com> 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.
> Date: Thu, 24 Apr 2008 10:08:16 +0100 > From: mich...@mahemoff.com > To: opensocial-api@googlegroups.com > 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 > <api.kur...@google.com> 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 <mich...@mahemoff.com> > > 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 <mich...@mahemoff.com> > > 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 > > <api.kur...@google.com> 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.
> > > > > On Tue, Apr 22, 2008 at 5:22 AM, Michael Mahemoff > > <mich...@mahemoff.com> 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.
|
