[
https://issues.apache.org/jira/browse/WICKET-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Guay-Paquet updated WICKET-4161:
-----------------------------------------
Description:
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, but resolves the issue
by intercepting all renderJavaScript* methods and keeping their order.
was:
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.
> 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
> Labels: javascript, resource
>
> 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, but resolves the
> issue by intercepting all renderJavaScript* methods and keeping their order.
--
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
