AbstractResourceAggregatingHeaderResponse does not order javascript properly
----------------------------------------------------------------------------
Key: WICKET-4161
URL: https://issues.apache.org/jira/browse/WICKET-4161
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5.1
Reporter: Bertrand Guay-Paquet
I decided to give AbstractResourceAggregatingHeaderResponse a try but I found a
problem in its design that, I think, makes it unusable.
How it works:
1-the IHeaderResponse#renderJavaScriptReference(ResourceReference) methods are
intercepted and the resource references are stored in a list and not rendered
right away. Each resource ref is assigned a key for grouping.
2-When close() is called on the response, the aggregator writes out all the
accumulated resource references which have not been rendered yet. This step can
be used to group multiple resources into a single merged resource.
The problem:
AbstractResourceAggregatingHeaderResponse does not intercept calls to
IHeaderResponse#renderJavaScriptReference(url) or
IHeaderResponse#renderJavaScript(Script). They are directly executed by the
underlying response.
example:
AbstractDefaultAjaxBehavior#renderHead() does the following :
response.renderJavaScriptReference(WicketEventReference.INSTANCE);
response.renderJavaScriptReference(WicketAjaxReference.INSTANCE);
response.renderJavaScript("Wicket.Ajax.baseUrl=[...]");
With the non-aggregating header response, the Wicket .js ref script tags are
rendered in the markup before the inline javascript code and all is well.
With the aggregating version, the Wicket js resource references are rendered
last (in close()). This means that the inline javascript code (which uses
Wicket.Ajax) is executed before the Wicket .js files are loaded, causing a
javascript error (Wicket is undefined).
This problem also applies to css resource references because order of inclusion
is important for them too.
Short of a big refactor to force each rendered javascript to list its
dependencies, I don't see how this problem can be solved. I opened this ticket
primarily to share my findings and let people comment on possible solutions
other than removing the code.
The problem is also present in
AbstractDependencyRespectingResourceAggregatingHeaderResponse.
NOTE:
wiQuery uses AbstractResourceAggregatingHeaderResponse so it is exposed to this
problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
