[
https://issues.apache.org/jira/browse/WICKET-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16349087#comment-16349087
]
Korbinian Bachl commented on WICKET-6498:
-----------------------------------------
How will this wicket-defer-finished.js look like? The problem I see is that we
have no way to be certain that the defer JS gets run first or the inline JS....
What happens when here the defer.js gets loaded and executed while the inline
is not yet ready (its in parallel!)? Then the event fires before all listeners
are registered.... the only save way IMHO would be if wicket created a 2nd
external temporary resource file that gets loaded defer and contains the logic
needed, as we then can be certain that the first defer got loaded and parsed
and executed before.... e.g.: offload the inline to external
> 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: 7.9.0, 8.0.0-M8
> Reporter: Korbinian Bachl
> Assignee: Sven Meier
> Priority: Minor
> Fix For: 8.0.0
>
> 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
(v7.6.3#76005)
