Ajax POST stopped because of precondition check
Hello,
I've got a problem while integrating a JQuery Slider in a project that
I'm working on. The basic idea is that when the value of the slider
changes, a hidden textfield is changed as well and the value of this
textfield is submitted using an AjaxFormComponentUpdatingBehavior. This
is all working in Firefox, but in IE7 the ajax callback isn't fired.
When the slider is changed I see the following message in the Ajax Debug
log: *: *INFO: Ajax POST stopped because of precondition check,
url:?wicket:interface=:3:formulier:opslaanform:pagina:0:element:elementen:0:element:vraagPanelContent:indentContainer:invoer:sliderPanel:slidercontainer:slider:valueField::IActivePageBehaviorListener:0:-1wicket:ignoreIfNotActive=true
The following is the part of the generated HTML that takes care of this:
div aria-disabled=false id=id2e style=width: 785px;
class=center ui-slider ui-widget ui-widget-content ui-corner-all
ui-slider-horizontaldiv style=left: 25%;
class=ui-slider-handle ui-state-default ui-corner-all/div/div
input id=id28
name=pagina:0:element:elementen:0:element:vraagPanelContent:indentContainer:invoer:sliderPanel:slidercontainer:slider:valueField
value=1 onchange=var wcall=wicketSubmitFormById('id9',
'?wicket:interface=:3:formulier:opslaanform:pagina:0:element:elementen:0:element:vraagPanelContent:indentContainer:invoer:sliderPanel:slidercontainer:slider:valueField::IActivePageBehaviorListener:0:-1amp;wicket:ignoreIfNotActive=true',
null,null,null, function() {return
Wicket.$$(this)amp;amp;Wicket.$$('id9')}.bind(this));;
type=hidden
script$('#id2e').slider({min: 0, max: 4, change: function (e, ui)
{ document.getElementById('id28').value = ui.value; var ajaxCall =
eval(document.getElementById('id28').onchange); ajaxCall(e);},
steps: 4}).slider('enable');/script
Does anyone have an idea about what is going wrong here?
Thanks in advance
Rik Overvelde
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageParameters in wicket 1.2.7 problem
This is what the 1.2 javadoc says about it:
protected WebPage(PageParameters parameters)
Constructor which receives wrapped query string parameters for a
request. Having this constructor public means that your page is
'bookmarkable' and hence can be called/ created from anywhere. For
bookmarkable pages (as opposed to when you construct page instances
yourself, this constructor will be used in preference to a no-arg
constructor, if both exist. Note that nothing is done with the page
parameters argument. This constructor is provided so that tools such as
IDEs will include it their list of suggested constructors for derived
classes.
So passing it down should not make any difference.
I've solved the problem using the cookies tip by the way, thanks for the
help.
Martijn Dashorst wrote:
IIRC You should pass in the page parameters all the way down to the Wicket page:
super(parameters, Valideren gegevens)
Martijn
On Mon, Nov 3, 2008 at 8:41 AM, Rik Overvelde [EMAIL PROTECTED] wrote:
Basically, the code that executes is:
public ValidatePage(PageParameters parameters)
{
super(Valideren gegevens);
String code = parameters.getString(code);
If I put a breakpoint right after this, I already get the incorrect
code. The page that I use extends a page that contains the basic layout/menu
from the page, but that page does no redirecting either.
I'm reading up on the session sharing, but from what I can see that is not
recommended because of security issues. I didn't think about using cookies
though, so thanks for that suggestion. That sounds like it would be the best
solution.
Nino Saturnino Martinez Vazquez Wael wrote:
Strange, but as you said you had the idea that it could be a bug. But it
still strikes me a bit strange that the page are redirected, and results in
an modifified link.. Could you provide a cut out of the code?
Otherwise the idea with the servlet should be fine, I think you can enable
shared sessions somewhere in tomcat at least... Otherwise you could do it
with an encrypted session cookie..
Rik Overvelde wrote:
Hi Nino,
I don't link to the verification page from inside the application itself.
Instead, the link is send in an email to the user when he changes his email
adress. When they click the link, the page is opened. In a lot of cases the
users are still logged in on the application, meaning that a second tab is
opened. If that is the case, the url changes in the way that I described. If
there is no other tab with the application open when the user clicks the
link, the page works fine (meaning that the page parameters are being read).
Also, when the bug occurs it triggers an error message which tells that the
given code is incorrect, which means that the page parameters are read at
that point as well.
Nino Saturnino Martinez Vazquez Wael wrote:
Hi Rik
Im not sure about this, it's been some months(if not years) since i've
touched 1.2.x. How are you linking to verification page when logged in, for
me it looks like you are not using pageparameters at all but instead just
instantiate the page with an other constructor..
Rik Overvelde wrote:
Hey everyone,
I'm having a problem with page parameters in wicket 1.2.7 when multiple
tabs are opened. I'm working on a verification system for email adresses,
which sends a mail with an url containing a guid to a user. I've mounted the
page using a queryStringUrlCodingStrategy which results in an address like:
http://page.com/verificatie?code=0572f18d-a9b1-4b92-bb89-7243b9e35d24.
When the link is opened while you're already logged in though, wicket
changes the url while loading in something like this:
http://page.com/verificatie?code=%5BLjava.lang.String%3B%4087bf0bwicket:pageMapName=wicket-0
From what I understand, this is a known issue with wicket 1.2 and is
solved in wicket 1.3. The application I'm working on however is already
fairly large and because of time constraints it is impossible right now to
migrate to 1.3 so I'm looking for a workaround for this.
One thing that I've been thinking about is to have the verification
link point you to a non wicket servlet, which writes the guid to its
session, then forwards you to a wicket page that retrieves the guid from the
other servlets session. Is there a way to get the other servlets session in
wicket?
If anyone has another suggestions for getting around this problem I'd
love to hear it.
With regards,
Rik Overvelde
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
Re: PageParameters in wicket 1.2.7 problem
Hi Nino, I don't link to the verification page from inside the application itself. Instead, the link is send in an email to the user when he changes his email adress. When they click the link, the page is opened. In a lot of cases the users are still logged in on the application, meaning that a second tab is opened. If that is the case, the url changes in the way that I described. If there is no other tab with the application open when the user clicks the link, the page works fine (meaning that the page parameters are being read). Also, when the bug occurs it triggers an error message which tells that the given code is incorrect, which means that the page parameters are read at that point as well. Nino Saturnino Martinez Vazquez Wael wrote: Hi Rik Im not sure about this, it's been some months(if not years) since i've touched 1.2.x. How are you linking to verification page when logged in, for me it looks like you are not using pageparameters at all but instead just instantiate the page with an other constructor.. Rik Overvelde wrote: Hey everyone, I'm having a problem with page parameters in wicket 1.2.7 when multiple tabs are opened. I'm working on a verification system for email adresses, which sends a mail with an url containing a guid to a user. I've mounted the page using a queryStringUrlCodingStrategy which results in an address like: http://page.com/verificatie?code=0572f18d-a9b1-4b92-bb89-7243b9e35d24. When the link is opened while you're already logged in though, wicket changes the url while loading in something like this: http://page.com/verificatie?code=%5BLjava.lang.String%3B%4087bf0bwicket:pageMapName=wicket-0 From what I understand, this is a known issue with wicket 1.2 and is solved in wicket 1.3. The application I'm working on however is already fairly large and because of time constraints it is impossible right now to migrate to 1.3 so I'm looking for a workaround for this. One thing that I've been thinking about is to have the verification link point you to a non wicket servlet, which writes the guid to its session, then forwards you to a wicket page that retrieves the guid from the other servlets session. Is there a way to get the other servlets session in wicket? If anyone has another suggestions for getting around this problem I'd love to hear it. With regards, Rik Overvelde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PageParameters in wicket 1.2.7 problem
Basically, the code that executes is:
public ValidatePage(PageParameters parameters)
{
super(Valideren gegevens);
String code = parameters.getString(code);
If I put a breakpoint right after this, I already get the incorrect
code. The page that I use extends a page that contains the basic
layout/menu from the page, but that page does no redirecting either.
I'm reading up on the session sharing, but from what I can see that is
not recommended because of security issues. I didn't think about using
cookies though, so thanks for that suggestion. That sounds like it would
be the best solution.
Nino Saturnino Martinez Vazquez Wael wrote:
Strange, but as you said you had the idea that it could be a bug. But
it still strikes me a bit strange that the page are redirected, and
results in an modifified link.. Could you provide a cut out of the code?
Otherwise the idea with the servlet should be fine, I think you can
enable shared sessions somewhere in tomcat at least... Otherwise you
could do it with an encrypted session cookie..
Rik Overvelde wrote:
Hi Nino,
I don't link to the verification page from inside the application
itself. Instead, the link is send in an email to the user when he
changes his email adress. When they click the link, the page is
opened. In a lot of cases the users are still logged in on the
application, meaning that a second tab is opened. If that is the
case, the url changes in the way that I described. If there is no
other tab with the application open when the user clicks the link,
the page works fine (meaning that the page parameters are being
read). Also, when the bug occurs it triggers an error message which
tells that the given code is incorrect, which means that the page
parameters are read at that point as well.
Nino Saturnino Martinez Vazquez Wael wrote:
Hi Rik
Im not sure about this, it's been some months(if not years) since
i've touched 1.2.x. How are you linking to verification page when
logged in, for me it looks like you are not using pageparameters at
all but instead just instantiate the page with an other constructor..
Rik Overvelde wrote:
Hey everyone,
I'm having a problem with page parameters in wicket 1.2.7 when
multiple tabs are opened. I'm working on a verification system for
email adresses, which sends a mail with an url containing a guid to
a user. I've mounted the page using a queryStringUrlCodingStrategy
which results in an address like:
http://page.com/verificatie?code=0572f18d-a9b1-4b92-bb89-7243b9e35d24.
When the link is opened while you're already logged in though,
wicket changes the url while loading in something like this:
http://page.com/verificatie?code=%5BLjava.lang.String%3B%4087bf0bwicket:pageMapName=wicket-0
From what I understand, this is a known issue with wicket 1.2 and
is solved in wicket 1.3. The application I'm working on however is
already fairly large and because of time constraints it is
impossible right now to migrate to 1.3 so I'm looking for a
workaround for this.
One thing that I've been thinking about is to have the verification
link point you to a non wicket servlet, which writes the guid to
its session, then forwards you to a wicket page that retrieves the
guid from the other servlets session. Is there a way to get the
other servlets session in wicket?
If anyone has another suggestions for getting around this problem
I'd love to hear it.
With regards,
Rik Overvelde
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
PageParameters in wicket 1.2.7 problem
Hey everyone, I'm having a problem with page parameters in wicket 1.2.7 when multiple tabs are opened. I'm working on a verification system for email adresses, which sends a mail with an url containing a guid to a user. I've mounted the page using a queryStringUrlCodingStrategy which results in an address like: http://page.com/verificatie?code=0572f18d-a9b1-4b92-bb89-7243b9e35d24. When the link is opened while you're already logged in though, wicket changes the url while loading in something like this: http://page.com/verificatie?code=%5BLjava.lang.String%3B%4087bf0bwicket:pageMapName=wicket-0 From what I understand, this is a known issue with wicket 1.2 and is solved in wicket 1.3. The application I'm working on however is already fairly large and because of time constraints it is impossible right now to migrate to 1.3 so I'm looking for a workaround for this. One thing that I've been thinking about is to have the verification link point you to a non wicket servlet, which writes the guid to its session, then forwards you to a wicket page that retrieves the guid from the other servlets session. Is there a way to get the other servlets session in wicket? If anyone has another suggestions for getting around this problem I'd love to hear it. With regards, Rik Overvelde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
