RE: EmptyAjaxRequestTarget invokes failurescript when link is pressed on page
Hi,
It seems that there are not yet any commits made to snapshot regarding this.
- Mikko
-Original Message-
From: Mikko Pukki [mailto:mikko.pu...@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.kn...@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 mikko.pu...@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=truerandom=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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
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.kn...@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 mikko.pu...@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=truerandom=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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
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 mikko.pu...@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=truerandom=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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
