You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Mikko Pukki <Mi...@syncrontech.com> on 2009/04/07 15:30:32 UTC

EmptyAjaxRequestTarget invokes failurescript when link is pressed on page

Hi,

We just noticed that if user is on a page and ajax request is
executing, pressing a link can cause AbstractDefaultAjaxBehavior's
failurescript to be executed on the browser.

We noticed that this happens at least in cases where pressing a link
forwards user to other page by setting a different response page.

Content of ajax debug is same as in the jira issue I have posted before
(JIRA 1971):

    INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
    INFO: Invoking pre-call handler(s)...
    INFO: Received ajax response (31 characters)
    INFO:
    <ajax-response></ajax-response>
    ERROR: Error while parsing response: Could not find root <ajax-response> element
    INFO: Invoking post-call handler(s)...

Content of the ajax response is problem at least on ie6,ie7,ff2 and ff3. It seems
to fail, because xml reply does not contain doctype.

This is annoying, because the invoker of the ajax request is in our case inherited from the
AbstractAjaxTimerBehavior and we would like to do a page reload in the failurescript in case
that request fails so that page would still be updated even if there are some network problems.
Now pressing any link that forwards to other pages can force a reload to the
page, if some request is already executing. In this particular application this is wery common,
partly because of bad network connection from the client's site (request can take some time)
and partly because of very frequent ajax requests.

We tried to modify org.apache.wicket.request.target.basic.EmptyAjaxRequestTarget's
respond method so that it puts doctype to the respond as does the normal ajax target

we replaced this:
	public void respond(RequestCycle requestCycle)
	{
		requestCycle.getResponse().write("<ajax-response></ajax-response>");
	}

with this:
	public void respond(RequestCycle requestCycle)
	{
		final WebResponse response = (WebResponse)requestCycle.getResponse();
		final Application app = Application.get();
		final String encoding = app.getRequestCycleSettings().getResponseRequestEncoding();

		// Set content type based on markup type for page
		response.setCharacterEncoding(encoding);
		response.setContentType("text/xml; charset=" + encoding);

		// Make sure it is not cached by a client
		response.setHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT");
		response.setHeader("Cache-Control", "no-cache, must-revalidate");
		response.setHeader("Pragma", "no-cache");

		response.write("<?xml version=\"1.0\" encoding=\"");
		response.write(encoding);
		response.write("\"?>");
		response.write("<ajax-response></ajax-response>");
	}

And it works now. Should I open a jira issue for this?

Regards,
Mikko

------------------
Mikko Pukki
Syncron Tech Oy
Laserkatu 6
53850 Lappeenranta
+358 400 757 178


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


RE: EmptyAjaxRequestTarget invokes failurescript when link is pressed on page

Posted by Mikko Pukki <Mi...@syncrontech.com>.
Hi,

It seems that there are not yet any commits made to snapshot regarding this.

- Mikko

-----Original Message-----
From: Mikko Pukki [mailto:Mikko.Pukki@syncrontech.com] 
Sent: 8. huhtikuuta 2009 11:04
To: users@wicket.apache.org
Subject: RE: EmptyAjaxRequestTarget invokes failurescript when link is pressed on page

Hi,

I attached a patch (for 1.3.x snapshot) to jira 1971.

- Mikko

-----Original Message-----
From: Matej Knopp [mailto:matej.knopp@gmail.com] 
Sent: 7. huhtikuuta 2009 20:17
To: users@wicket.apache.org
Subject: Re: EmptyAjaxRequestTarget invokes failurescript when link is pressed on page

Please open jira issue - or assign the code you posted to existing
one. I'll apply it.

-Matej

On Tue, Apr 7, 2009 at 3:30 PM, Mikko Pukki <Mi...@syncrontech.com> wrote:
> Hi,
>
> We just noticed that if user is on a page and ajax request is
> executing, pressing a link can cause AbstractDefaultAjaxBehavior's
> failurescript to be executed on the browser.
>
> We noticed that this happens at least in cases where pressing a link
> forwards user to other page by setting a different response page.
>
> Content of ajax debug is same as in the jira issue I have posted before
> (JIRA 1971):
>
>    INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
>    INFO: Invoking pre-call handler(s)...
>    INFO: Received ajax response (31 characters)
>    INFO:
>    <ajax-response></ajax-response>
>    ERROR: Error while parsing response: Could not find root <ajax-response> element
>    INFO: Invoking post-call handler(s)...
>
> Content of the ajax response is problem at least on ie6,ie7,ff2 and ff3. It seems
> to fail, because xml reply does not contain doctype.
>
> This is annoying, because the invoker of the ajax request is in our case inherited from the
> AbstractAjaxTimerBehavior and we would like to do a page reload in the failurescript in case
> that request fails so that page would still be updated even if there are some network problems.
> Now pressing any link that forwards to other pages can force a reload to the
> page, if some request is already executing. In this particular application this is wery common,
> partly because of bad network connection from the client's site (request can take some time)
> and partly because of very frequent ajax requests.
>
> We tried to modify org.apache.wicket.request.target.basic.EmptyAjaxRequestTarget's
> respond method so that it puts doctype to the respond as does the normal ajax target
>
> we replaced this:
>        public void respond(RequestCycle requestCycle)
>        {
>                requestCycle.getResponse().write("<ajax-response></ajax-response>");
>        }
>
> with this:
>        public void respond(RequestCycle requestCycle)
>        {
>                final WebResponse response = (WebResponse)requestCycle.getResponse();
>                final Application app = Application.get();
>                final String encoding = app.getRequestCycleSettings().getResponseRequestEncoding();
>
>                // Set content type based on markup type for page
>                response.setCharacterEncoding(encoding);
>                response.setContentType("text/xml; charset=" + encoding);
>
>                // Make sure it is not cached by a client
>                response.setHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT");
>                response.setHeader("Cache-Control", "no-cache, must-revalidate");
>                response.setHeader("Pragma", "no-cache");
>
>                response.write("<?xml version=\"1.0\" encoding=\"");
>                response.write(encoding);
>                response.write("\"?>");
>                response.write("<ajax-response></ajax-response>");
>        }
>
> And it works now. Should I open a jira issue for this?
>
> Regards,
> Mikko
>
> ------------------
> Mikko Pukki
> Syncron Tech Oy
> Laserkatu 6
> 53850 Lappeenranta
> +358 400 757 178
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


RE: EmptyAjaxRequestTarget invokes failurescript when link is pressed on page

Posted by Mikko Pukki <Mi...@syncrontech.com>.
Hi,

I attached a patch (for 1.3.x snapshot) to jira 1971.

- Mikko

-----Original Message-----
From: Matej Knopp [mailto:matej.knopp@gmail.com] 
Sent: 7. huhtikuuta 2009 20:17
To: users@wicket.apache.org
Subject: Re: EmptyAjaxRequestTarget invokes failurescript when link is pressed on page

Please open jira issue - or assign the code you posted to existing
one. I'll apply it.

-Matej

On Tue, Apr 7, 2009 at 3:30 PM, Mikko Pukki <Mi...@syncrontech.com> wrote:
> Hi,
>
> We just noticed that if user is on a page and ajax request is
> executing, pressing a link can cause AbstractDefaultAjaxBehavior's
> failurescript to be executed on the browser.
>
> We noticed that this happens at least in cases where pressing a link
> forwards user to other page by setting a different response page.
>
> Content of ajax debug is same as in the jira issue I have posted before
> (JIRA 1971):
>
>    INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
>    INFO: Invoking pre-call handler(s)...
>    INFO: Received ajax response (31 characters)
>    INFO:
>    <ajax-response></ajax-response>
>    ERROR: Error while parsing response: Could not find root <ajax-response> element
>    INFO: Invoking post-call handler(s)...
>
> Content of the ajax response is problem at least on ie6,ie7,ff2 and ff3. It seems
> to fail, because xml reply does not contain doctype.
>
> This is annoying, because the invoker of the ajax request is in our case inherited from the
> AbstractAjaxTimerBehavior and we would like to do a page reload in the failurescript in case
> that request fails so that page would still be updated even if there are some network problems.
> Now pressing any link that forwards to other pages can force a reload to the
> page, if some request is already executing. In this particular application this is wery common,
> partly because of bad network connection from the client's site (request can take some time)
> and partly because of very frequent ajax requests.
>
> We tried to modify org.apache.wicket.request.target.basic.EmptyAjaxRequestTarget's
> respond method so that it puts doctype to the respond as does the normal ajax target
>
> we replaced this:
>        public void respond(RequestCycle requestCycle)
>        {
>                requestCycle.getResponse().write("<ajax-response></ajax-response>");
>        }
>
> with this:
>        public void respond(RequestCycle requestCycle)
>        {
>                final WebResponse response = (WebResponse)requestCycle.getResponse();
>                final Application app = Application.get();
>                final String encoding = app.getRequestCycleSettings().getResponseRequestEncoding();
>
>                // Set content type based on markup type for page
>                response.setCharacterEncoding(encoding);
>                response.setContentType("text/xml; charset=" + encoding);
>
>                // Make sure it is not cached by a client
>                response.setHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT");
>                response.setHeader("Cache-Control", "no-cache, must-revalidate");
>                response.setHeader("Pragma", "no-cache");
>
>                response.write("<?xml version=\"1.0\" encoding=\"");
>                response.write(encoding);
>                response.write("\"?>");
>                response.write("<ajax-response></ajax-response>");
>        }
>
> And it works now. Should I open a jira issue for this?
>
> Regards,
> Mikko
>
> ------------------
> Mikko Pukki
> Syncron Tech Oy
> Laserkatu 6
> 53850 Lappeenranta
> +358 400 757 178
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: EmptyAjaxRequestTarget invokes failurescript when link is pressed on page

Posted by Matej Knopp <ma...@gmail.com>.
Please open jira issue - or assign the code you posted to existing
one. I'll apply it.

-Matej

On Tue, Apr 7, 2009 at 3:30 PM, Mikko Pukki <Mi...@syncrontech.com> wrote:
> Hi,
>
> We just noticed that if user is on a page and ajax request is
> executing, pressing a link can cause AbstractDefaultAjaxBehavior's
> failurescript to be executed on the browser.
>
> We noticed that this happens at least in cases where pressing a link
> forwards user to other page by setting a different response page.
>
> Content of ajax debug is same as in the jira issue I have posted before
> (JIRA 1971):
>
>    INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
>    INFO: Invoking pre-call handler(s)...
>    INFO: Received ajax response (31 characters)
>    INFO:
>    <ajax-response></ajax-response>
>    ERROR: Error while parsing response: Could not find root <ajax-response> element
>    INFO: Invoking post-call handler(s)...
>
> Content of the ajax response is problem at least on ie6,ie7,ff2 and ff3. It seems
> to fail, because xml reply does not contain doctype.
>
> This is annoying, because the invoker of the ajax request is in our case inherited from the
> AbstractAjaxTimerBehavior and we would like to do a page reload in the failurescript in case
> that request fails so that page would still be updated even if there are some network problems.
> Now pressing any link that forwards to other pages can force a reload to the
> page, if some request is already executing. In this particular application this is wery common,
> partly because of bad network connection from the client's site (request can take some time)
> and partly because of very frequent ajax requests.
>
> We tried to modify org.apache.wicket.request.target.basic.EmptyAjaxRequestTarget's
> respond method so that it puts doctype to the respond as does the normal ajax target
>
> we replaced this:
>        public void respond(RequestCycle requestCycle)
>        {
>                requestCycle.getResponse().write("<ajax-response></ajax-response>");
>        }
>
> with this:
>        public void respond(RequestCycle requestCycle)
>        {
>                final WebResponse response = (WebResponse)requestCycle.getResponse();
>                final Application app = Application.get();
>                final String encoding = app.getRequestCycleSettings().getResponseRequestEncoding();
>
>                // Set content type based on markup type for page
>                response.setCharacterEncoding(encoding);
>                response.setContentType("text/xml; charset=" + encoding);
>
>                // Make sure it is not cached by a client
>                response.setHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT");
>                response.setHeader("Cache-Control", "no-cache, must-revalidate");
>                response.setHeader("Pragma", "no-cache");
>
>                response.write("<?xml version=\"1.0\" encoding=\"");
>                response.write(encoding);
>                response.write("\"?>");
>                response.write("<ajax-response></ajax-response>");
>        }
>
> And it works now. Should I open a jira issue for this?
>
> Regards,
> Mikko
>
> ------------------
> Mikko Pukki
> Syncron Tech Oy
> Laserkatu 6
> 53850 Lappeenranta
> +358 400 757 178
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: EmptyAjaxRequestTarget invokes failurescript when link is pressed on page

Posted by Johan Compagner <jc...@gmail.com>.
This is already fixed in the release of 1.3.6

Need to look at if i already ported this to 1.4

On Tue, Apr 7, 2009 at 15:30, Mikko Pukki <Mi...@syncrontech.com>wrote:

> Hi,
>
> We just noticed that if user is on a page and ajax request is
> executing, pressing a link can cause AbstractDefaultAjaxBehavior's
> failurescript to be executed on the browser.
>
> We noticed that this happens at least in cases where pressing a link
> forwards user to other page by setting a different response page.
>
> Content of ajax debug is same as in the jira issue I have posted before
> (JIRA 1971):
>
>    INFO: Initiating Ajax POST request on ?
> wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
>    INFO: Invoking pre-call handler(s)...
>    INFO: Received ajax response (31 characters)
>    INFO:
>    <ajax-response></ajax-response>
>    ERROR: Error while parsing response: Could not find root <ajax-response>
> element
>    INFO: Invoking post-call handler(s)...
>
> Content of the ajax response is problem at least on ie6,ie7,ff2 and ff3. It
> seems
> to fail, because xml reply does not contain doctype.
>
> This is annoying, because the invoker of the ajax request is in our case
> inherited from the
> AbstractAjaxTimerBehavior and we would like to do a page reload in the
> failurescript in case
> that request fails so that page would still be updated even if there are
> some network problems.
> Now pressing any link that forwards to other pages can force a reload to
> the
> page, if some request is already executing. In this particular application
> this is wery common,
> partly because of bad network connection from the client's site (request
> can take some time)
> and partly because of very frequent ajax requests.
>
> We tried to modify
> org.apache.wicket.request.target.basic.EmptyAjaxRequestTarget's
> respond method so that it puts doctype to the respond as does the normal
> ajax target
>
> we replaced this:
>        public void respond(RequestCycle requestCycle)
>        {
>
>  requestCycle.getResponse().write("<ajax-response></ajax-response>");
>        }
>
> with this:
>        public void respond(RequestCycle requestCycle)
>        {
>                final WebResponse response =
> (WebResponse)requestCycle.getResponse();
>                final Application app = Application.get();
>                final String encoding =
> app.getRequestCycleSettings().getResponseRequestEncoding();
>
>                // Set content type based on markup type for page
>                response.setCharacterEncoding(encoding);
>                response.setContentType("text/xml; charset=" + encoding);
>
>                // Make sure it is not cached by a client
>                response.setHeader("Expires", "Mon, 26 Jul 1997 05:00:00
> GMT");
>                response.setHeader("Cache-Control", "no-cache,
> must-revalidate");
>                response.setHeader("Pragma", "no-cache");
>
>                response.write("<?xml version=\"1.0\" encoding=\"");
>                response.write(encoding);
>                response.write("\"?>");
>                response.write("<ajax-response></ajax-response>");
>        }
>
> And it works now. Should I open a jira issue for this?
>
> Regards,
> Mikko
>
> ------------------
> Mikko Pukki
> Syncron Tech Oy
> Laserkatu 6
> 53850 Lappeenranta
> +358 400 757 178
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>