In Wicket-1.5, this already is the case. So I guess, you'll have to upgrade...
On Friday 30 September 2011 09:49:51 Martin Makundi wrote: > Yes but you don't want to code special cases for all your components > renderhead to detect if is ajax or not. Is better to always use same > smart method which knows how to handle ajax/non-ajax. > > ** > Martin > > 2011/9/30 Emond Papegaaij <[email protected]>: > > IMHO, you should not use any ready event in AJAX, you should just > > evaluate the statements after updating the DOM. AFAIC, this is what > > AjaxHeaderResponse does for calls to renderOnDomReadyJavaScript. > > > > On Friday 30 September 2011 09:30:58 Martin Makundi wrote: > >> The problem with qjuery domready is that it ALWAYS renders domready. > >> However, current wicket domready works such that for example in ajax > >> events it executes immediately. You can see the difference if you have > >> "jquery skinned components", a huge delay if using jquery.domready in > >> general and quite fast if you use wicket domready. > >> > >> Such built in logic could ofcourse be built into a new implementation > >> of the event. > >> > >> ** > >> Martin > >> > >> 2011/9/30 Emond Papegaaij <[email protected]>: > >> > This will not be applied before wicket.next. Until then, I think we > >> > should really reconsider the current domready implementation on IE. > >> > Perhaps, we can 'borrow' JQuery's ready implementation for now? > >> > > >> > On Friday 30 September 2011 09:18:32 Martin Makundi wrote: > >> >> Umh.. not 1.4.17? We are in 1.4.17. > >> >> > >> >> 2011/9/30 Martin Makundi <[email protected]>: > >> >> > This affects 1.4 also? > >> >> > > >> >> > 2011/9/30 Martin Grigorov <[email protected]>: > >> >> >> Hopefully with https://github.com/martin-g/wicket/tree/ajax-jquery > >> >> >> merged in Wicket.next this kind of problems will be much less > >> >> >> > >> >> >> This branch is work in progress. > >> >> >> > >> >> >> On Fri, Sep 30, 2011 at 8:56 AM, Emond Papegaaij > >> >> >> > >> >> >> <[email protected]> wrote: > >> >> >>> Even though we came up with the fix ourselves, it did not solve > >> >> >>> the problem for us in all cases. The fix for 4080 fixed one of > >> >> >>> our apps, but the other still is very broken. Someone with > >> >> >>> knowledge about domready in IE should really look at this. We've > >> >> >>> abandoned wicket's domready and now use WiQuery to pass all > >> >> >>> domready events to JQuery's $(document).ready(), which works > >> >> >>> fine. > >> >> >>> > >> >> >>> Best regards, > >> >> >>> Emond > >> >> >>> > >> >> >>> On Friday 30 September 2011 08:49:46 Martin Grigorov wrote: > >> >> >>>> It seems there is an update for IE that broke the state ... > >> >> >>>> See also https://issues.apache.org/jira/browse/WICKET-4080 > >> >> >>>> > >> >> >>>> On Fri, Sep 30, 2011 at 8:27 AM, Martin Makundi > >> >> >>>> > >> >> >>>> <[email protected]> wrote: > >> >> >>>> > Hi! > >> >> >>>> > > >> >> >>>> > I have noticed lots of document.body=null situations with > >> >> >>>> > domready in IE, I am currently trying out the following fix to > >> >> >>>> > wicket-event.js: > >> >> >>>> > > >> >> >>>> > var domReady = function() { > >> >> >>>> > function > >> >> >>>> > onBodyLoadedSafely() { if (document.body) { if > >> >> >>>> > (window.loaded) return; window.loaded = true; > >> >> >>>> > > >> >> >>>> > // > >> >> >>>> > invoke the handlers Wicket.Event.fireDomReadyHandlers(); } > >> >> >>>> > else { > >> >> >>>> > > >> >> >>>> > window.setTimeout(onBodyLoadedSafely, 100); } > >> >> >>>> > } > >> >> >>>> > > >> >> >>>> > onBodyLoadedSafely(); > >> >> >>>> > }.bind(this); > >> >> >>>> > > >> >> >>>> > > >> >> >>>> > Domready is postponed until document.body > >> >> >>>> > > >> >> >>>> > > >> >> >>>> > ** > >> >> >>>> > Martin > >> >> >> > >> >> >> -- > >> >> >> Martin Grigorov > >> >> >> jWeekend > >> >> >> Training, Consulting, Development > >> >> >> http://jWeekend.com
