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 :-)
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)
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
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
