[
https://issues.apache.org/jira/browse/WICKET-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16352788#comment-16352788
]
Korbinian Bachl commented on WICKET-6498:
-----------------------------------------
[~svenmeier] I'm not sure that would work. The Problem here IMHO is that the
'DOMContentLoaded' is used by chrome and FF already outside the spec, as that
originally stated that it gets fired after all DOM operations are ready and
they ignore the fact that defer and async put scripts get there before....
thats why the DOMContentLoaded worked till some time ago.
Waiting onLoad is also a bad idea as it can take too long...
Currently in wicket all is added to a Wicket.Ajax.ajax object... maybe we could
use that this one gets created at the first JS inline and that we can rely that
way that this is always existing...
e.g.:
<head>
<js-to-create-the-wicket-object>
<external complete wicket-defer-js>
<additional inline-js>
....
</head>
that way the wicket-object would be always existing and could get loaded with
instructions that are then executed in the external wicket script?
.... or we would re-use the current-page and a some kind of js param to it?
so e.g:
<head>
<external wicket-defer-js>
<external wicket-defer-js src="/foo/bar/page?getJS">
....
</head>
that way the head would not stuffed with inline and all JS would come from the
page instance?... No idea if this is possible with low work on it but that way
we would be 100% safe and even complete backwards compatible;
What do you think?
> 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)
