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%4087bf0b&wicket: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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]