[
https://issues.apache.org/jira/browse/WICKET-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13135080#comment-13135080
]
Bertrand Guay-Paquet commented on WICKET-4161:
----------------------------------------------
Your patch does fix the problem if grouping is only done by aggregating css and
js in 2 groups. However, the AbstractResourceAggregatingHeaderResponse is still
vulnerable to whatever aggregating method given by its subclass. My last
quickstart patch shows this problem. Of course, the newGroupingKey() method I
used was artificially manufactured explicitly to trigger the problem, but it
shows that the aggregating functionality can easily break the required ordering
of resources.
>From my understanding, the subclass
>AbstractDependencyRespectingResourceAggregatingHeaderResponse of
>AbstractResourceAggregatingHeaderResponse is designed to overcome this issue
>by using ResourceDependentResourceReference. However, no part of Wicket
>currently uses the latter so a simple dependent ordering like the one in
>AbstractDefaultAjaxBehavior#renderHead() is still vulnerable.
> 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
> Assignee: Martin Grigorov
> Labels: javascript, resource
> Attachments: WICKET-4161.patch, WICKET-4161.zip, quickstart2.patch
>
>
> 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
