[
https://issues.apache.org/jira/browse/WICKET-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13135986#comment-13135986
]
Martin Grigorov commented on WICKET-4161:
-----------------------------------------
I think this is responsibility of the developer to provide proper
implementation of
org.apache.wicket.resource.aggregation.AbstractResourceAggregatingHeaderResponse.newGroupingKey(ResourceReferenceAndStringData).
The problem that Wicket itself doesn't use these classes should be discussed in
another ticket.
As I wrote in my mail to dev@ yesterday: we should decide which way to go:
improve the classes in o.a.w.resource.aggregation or use JavaScript library
that does this. For example RequireJS.
> 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
