On Fri, Jun 13, 2008 at 4:59 AM, Chris Chabot <[EMAIL PROTECTED]> wrote:
> On Jun 13, 2008, at 10:48 AM, Karsten Beyer wrote: > > 1) URL. A feature library is classified as type URL if the reference is >> made to either "http://.*"; or "/.*" (Note: https:// will be classified as >> file and fail. Not sure if that is intended.) >> >> > Thats a bug, thanks for reporting it :) > > 4) RESSOURCE. It is a valid type, but i did not find any further clue >> about it in the code. >> > > Resource means it's in a JAR file, obviously that wouldn't work in PHP > hence the lacking of code :-) There's no practical reason to support this in the PHP build, unless you had a separate store for the files that wasn't on disk. I don't think we even need res:// for the urls in the Java build anymore since I made it transitively carry through the resource vs. disk flag several months ago. > > > A quick fix would be to close the script tag and reference the type URL >> library in place and then reopen the script tag (instead of putting it into >> a buffer). A better fix would be to inline external libraries as well. This >> could however be quite hard to do, as they may contain external libraries as >> well. >> >> > Hmm ... Now i haven't done any deep investigation into this yet (i'm still > nurturing my first cup of coffee of the day), however i don't think that > would solve the problem? > > See the open social 'on load' handlers are called -before- the document's > onLoad has been completed, this is so that the gadget can start fetching > information and doing it's thing before all the images, external scripts etc > are done loading... great for fighting perceived latency! However it does > mean you can't count on any external resources being available, including > external javascripts. > > So even if we closed the </script> bit, put the <script src=....> and then > continued inline code that would depend on the external script, it would > still break on the initial execution. > > The 'fix' would be to work around this problem, ie don't depend on the > analytics code until the document has loaded by chaining your self to the > document.onload event.. or avoid depending on external javascript files all > together (as you can see there's not that many, i only know of the analytics > one.. and nothing depends on that) We do inline the external files in the Java build (unless the "inline" attribute is set to false). For analytics in particular, it really should just be a stub feature rather than referring to the url. The url doesn't do for anything -- it's ONLY there to allow old igoogle gadgets to work. > > Another issue with this is that the libs parameter is honored (in part) >> even if the gadget is type HTML. I don't think that this is a good idea. (i >> did not yet take a deeper look at the handling of type URL gadgets. e.g. if >> type URL libs are inlined into the combined file or not. In that case they >> could be included twice...) >> > > The libs param is to make part of the toolkit external and hence cashable > by the browser.. doing so would mean you couldn't run the on load handlers > bit of code until that file is loaded by the browser, but that should be > easy enough by moving it to the bottom of the external JS file :) I haven't > used that functionality my self yet, but it's exactly the same functionality > (and functioning) as you would find in the java version of shindig, and i > had reports of people using it there successfully If you don't support this, performance will be awful on pages with many gadgets (such as a typical "profile" or "dashboard" style page). The point of the libs parameter for type html gadgets is to get caching benefits by sending the same js bundle to all the gadgets on the page. The metadata example page (trunk/javascript/container/sample-metadata.html) shows how to use this. > > The dependency solving chain should keep the external libs in mind, and not > put anything in there twice though .. if it does that's a bug that we'd need > to fix, but i believe it does. > > type=url javascript features aren't inline into a external libs reference > though btw, we never inline url based features.. > > -- Chris >
