You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martin Makundi <ma...@koodaripalvelut.com> on 2011/09/30 08:27:09 UTC
Wicket 1.4.17 wicket-event.js domready
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
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
2011/9/30 Emond Papegaaij <em...@topicus.nl>:
> In Wicket-1.5, this already is the case. So I guess, you'll have to upgrade...
Is same in 1.4 also. IE is the problem, not wicket ;]
**
Martin
>
> 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 <em...@topicus.nl>:
>> > 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 <em...@topicus.nl>:
>> >> > 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 <ma...@koodaripalvelut.com>:
>> >> >> > This affects 1.4 also?
>> >> >> >
>> >> >> > 2011/9/30 Martin Grigorov <mg...@apache.org>:
>> >> >> >> 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
>> >> >> >>
>> >> >> >> <em...@topicus.nl> 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
>> >> >> >>>>
>> >> >> >>>> <ma...@koodaripalvelut.com> 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
>
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Emond Papegaaij <em...@topicus.nl>.
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 <em...@topicus.nl>:
> > 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 <em...@topicus.nl>:
> >> > 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 <ma...@koodaripalvelut.com>:
> >> >> > This affects 1.4 also?
> >> >> >
> >> >> > 2011/9/30 Martin Grigorov <mg...@apache.org>:
> >> >> >> 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
> >> >> >>
> >> >> >> <em...@topicus.nl> 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
> >> >> >>>>
> >> >> >>>> <ma...@koodaripalvelut.com> 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
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Sep 30, 2011 at 9:49 AM, Martin Makundi
<ma...@koodaripalvelut.com> 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 <em...@topicus.nl>:
>> 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 <em...@topicus.nl>:
>>> > 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 <ma...@koodaripalvelut.com>:
>>> >> > This affects 1.4 also?
>>> >> >
>>> >> > 2011/9/30 Martin Grigorov <mg...@apache.org>:
>>> >> >> 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
>>> >> >>
>>> >> >> <em...@topicus.nl> 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
>>> >> >>>>
>>> >> >>>> <ma...@koodaripalvelut.com> 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
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
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 <em...@topicus.nl>:
> 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 <em...@topicus.nl>:
>> > 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 <ma...@koodaripalvelut.com>:
>> >> > This affects 1.4 also?
>> >> >
>> >> > 2011/9/30 Martin Grigorov <mg...@apache.org>:
>> >> >> 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
>> >> >>
>> >> >> <em...@topicus.nl> 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
>> >> >>>>
>> >> >>>> <ma...@koodaripalvelut.com> 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
>
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Emond Papegaaij <em...@topicus.nl>.
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 <em...@topicus.nl>:
> > 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 <ma...@koodaripalvelut.com>:
> >> > This affects 1.4 also?
> >> >
> >> > 2011/9/30 Martin Grigorov <mg...@apache.org>:
> >> >> 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
> >> >>
> >> >> <em...@topicus.nl> 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
> >> >>>>
> >> >>>> <ma...@koodaripalvelut.com> 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
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
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 <em...@topicus.nl>:
> 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 <ma...@koodaripalvelut.com>:
>> > This affects 1.4 also?
>> >
>> > 2011/9/30 Martin Grigorov <mg...@apache.org>:
>> >> 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
>> >>
>> >> <em...@topicus.nl> 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
>> >>>>
>> >>>> <ma...@koodaripalvelut.com> 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
>
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Emond Papegaaij <em...@topicus.nl>.
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 <ma...@koodaripalvelut.com>:
> > This affects 1.4 also?
> >
> > 2011/9/30 Martin Grigorov <mg...@apache.org>:
> >> 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
> >>
> >> <em...@topicus.nl> 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
> >>>>
> >>>> <ma...@koodaripalvelut.com> 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
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
Umh.. not 1.4.17? We are in 1.4.17.
2011/9/30 Martin Makundi <ma...@koodaripalvelut.com>:
> This affects 1.4 also?
>
>
> 2011/9/30 Martin Grigorov <mg...@apache.org>:
>> 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
>> <em...@topicus.nl> 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
>>>>
>>>> <ma...@koodaripalvelut.com> 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
>>
>
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
This affects 1.4 also?
2011/9/30 Martin Grigorov <mg...@apache.org>:
> 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
> <em...@topicus.nl> 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
>>>
>>> <ma...@koodaripalvelut.com> 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
>
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Martin Grigorov <mg...@apache.org>.
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
<em...@topicus.nl> 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
>>
>> <ma...@koodaripalvelut.com> 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
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Emond Papegaaij <em...@topicus.nl>.
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
>
> <ma...@koodaripalvelut.com> 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
Re: Wicket 1.4.17 wicket-event.js domready
Posted by Martin Grigorov <mg...@apache.org>.
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
<ma...@koodaripalvelut.com> 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