Hi,
up front i have to admin that i do not yet have an complete overview
of the code, so maybe i miss something here. Also apologies for the
rather long mail...
This is about the outputHtmlGadget method in the
GadgetRenderingServlet class. The JS-Libraries are added in the right
order to the gadget object using the getIncludedFeatures and
addFeatureToResults methods of the Registry. The recursive nature of
the addFeatureToResults methods makes sure that the dependencies are
loaded before the feature itself.
However there are 3(or 4?) "types" of feature libraries (they are
classified by the <gadget> element in the feature.xml file):
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.)
2) INLINE. If there is no src attribute, the code is right there so it
should inlined.
3) FILE. If there is a src attribute, but it does not start with
http::// or /. The file is searched for in the features directory.
4) RESSOURCE. It is a valid type, but i did not find any further clue
about it in the code.
Now to the potential problem:
In the outputHtmGadget method the following logic is applied while
traversing all required libraries:
1) if it is type URL, it is added to a buffer string, which is output
after all other libraries and the forced libs.
2) if it is type INLINE, it is echoed directly
3) if it is type FILE(or Ressource), it is echoed if there are no
forced libs (which only depends on the GET['libs'] param, at this
point not on the config statement)
Then all forced libs are linked in one external file. Afterwards the
type URL scripts are linked.
I think that this logic will reorder the libraries and may cause
problems with dependencies. Let's make a simple example:
The analytics feature (i know that it is only a stub right now you can
exchange it for library A and B and so on...) is type URL. Let's say i
make a new feature analyticsplus which depends on analytics and
resides inside the features directory, so that it is type FILE.
With the above logic the output will look something like this:
<script...>
...some feature code...
...analyticsplus code...
...somme other feature code...
</script>
<script src="...path to analytics libs...">
As you can see the dependent library will be inlined and appear before
the dependency. This could cause severe problems.
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.
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...)
Best Regards,
Karsten Beyer
[EMAIL PROTECTED]
