On Fri, Sep 30, 2011 at 9:49 AM, Martin Makundi
<[email protected]> 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.
Agree.
As Emond said Wicket executes "manually" the domReady scripts in
XMLHttpRequest.onreadystatechange handler right after the components
update and before target.appendJavaScript() scripts.
Wicket assumes that the component is ready since the
replaceOuterHtml() phase is finished.
>
> **
> 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
>>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

Reply via email to