[
https://issues.apache.org/jira/browse/WICKET-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16307844#comment-16307844
]
ASF GitHub Bot commented on WICKET-6498:
----------------------------------------
GitHub user svenmeier opened a pull request:
https://github.com/apache/wicket/pull/253
WICKET-6498 deferred javascript
If addEventListener is used instead of jQuery "domready" and "load"
events, and OnLoadHeaderItem instead of JavaScriptHeaderItem, all JavaScript
resources can be deferred.
Open questions:
- does this solution work reliably on all browsers?
- who decides which JavaScript resources to defer and which not?
- how to handle cases where user code is still using a JavaScriptHeaderItem?
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/wicket WICKET-6498_deferred_javascript
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/wicket/pull/253.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #253
----
commit d77ba274f38953b6d5ab1088c7a9555111acd4fc
Author: Sven Meier <svenmeier@...>
Date: 2018-01-02T10:20:03Z
WICKET-6498 deferred javascript
use OnLoadHeaderItem instead of JavaScriptHeaderItem, addEventListener
instead of jQuery;
defer all JavaScript resources for now
----
> wicket 8 - js to asnyc and or defer
> -----------------------------------
>
> Key: WICKET-6498
> URL: https://issues.apache.org/jira/browse/WICKET-6498
> Project: Wicket
> Issue Type: New Feature
> Affects Versions: 8.0.0-M8
> Reporter: Korbinian Bachl
> Attachments: WICKET-6498-defer-support-2.patch,
> WICKET-6498-defer-support.patch
>
>
> I wonder if wicket cant even get better in the js part. Currently each page
> having ajax somehow ends up with following in the head:
> (1)<script type="text/javascript"
> src="./wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-2.2.4-ver-F9EE266EF993962AD59E804AD9DEBE66.js"></script>
> (2)<script type="text/javascript"
> src="./wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-event-jquery-ver-E34C6FE16C54FE3DF3591290A48A496A.js"></script>
> (3)<script type="text/javascript"
> src="./wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-F8010FEDC5FD9B05434A6023763E3050.js"></script>
> (4 - inline var and not really an issue)<script type="text/javascript"
> id="wicket-ajax-base-url">
> /*<![CDATA[*/
> Wicket.Ajax.baseUrl="/pagepath";
> /*]]>*/
> </script>
> (5)<script type="text/javascript" >
> /*<![CDATA[*/
> Wicket.Event.add(window, "domready", function(event) {
> wicketDebugBarCheckState();
> Wicket.Ajax.ajax({"u":"./effects?2-2.0-c1~link","c":"id6","e":"click","ch":"effects|d"});;
> Wicket.Ajax.ajax({"u":"./effects?2-2.0-c2~link","c":"id7","e":"click","ch":"effects|d","pd":true});;
> jQuery.noConflict();;
> Wicket.Event.publish(Wicket.Event.Topic.AJAX_HANDLERS_BOUND);
> ;});
> /*]]>*/
> </script>
> While 1,2 and 3 could be easily made at least defer, script 5 makes this
> impossible so far, having all 4 scripts lead to a slower DOMContentLoaded
> (requestet and executed 1 by 1), even these are not needed at that time and
> could IMHO be easily postponed to a time when the rendering tree is ready
> (and so dont block it);
> The real culprint IMHO is (5) and that it immediately needs the Wicket.Event
> object - so, I see 2 solutions for this:
> 1st: outline this code into a request specific js-src file that can be loaded
> like e.g.: <script defer src="/requesrt specific fake path">
> or
> 2nd: have it embedded into an
> window.addEventListener('DOMContentLoaded', function() {
> (function($) {
> $(document).ready(function() {
> // add the content here....
> });
> })(jQuery);
> });
> of even slim it down to:
> window.addEventListener('DOMContentLoaded', function() {
> (function($) {
> // add the content here....
> });
> });
> While 1 has the need to get 1 more request (even thats async thanks to
> defer), 2 seems to be clear of this and I cant think of any problem with that;
> What do you think?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
