You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Alex Rass <ar...@itbsllc.com> on 2010/10/07 01:59:54 UTC
urls after a form submission
Hi.
After an on-page (wicket) form is submitted, the followed url doesn't follow
the page's URL encoding strategy (QueryStringUrlCodingStrategy or any
others).
It just becomes "http://site.com/?wicket..." and loses original page
Could someone please tell me if there's a way to fix it easily?
Is this a bug that should be fixed or a normal behavior?
I REALLY need this working. Otherwise a 200 page site becomes a class
nightmare.
- Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: urls after a form submission
Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Oct 6, 2010 at 10:38 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
>
> Wrong. First, you have to understand what is happening behind the scenes.
> Look at the URL that actually appears in your form's "action" attribute -
> it is a full URL to a specific component, which will invoke the
> IFormSubmitListener on that component (i.e.
> ../?wicket:interface=:13:loginForm::IFormSubmitListener::). After that form
> is done processing, you are redirected to a URL to render whatever page is
> supposed to be rendered. If you haven't specifically called
> "setResponsePage(...)", then this means that Wicket hast re-render the page
> that your form was on. BUT - it can't send you back to a bookmarkable URL
> for that page (your pretty mount with query string parameters, etc), because
> your form submission could have changed all kinds of state on the page, and
> sending you to a bookmarkable URL will result in your page constructor
> getting called and rendering a new page (without all of those state
> changes). So, you must be redirected to the exact version of the page that
> your form just modified. Thus, you are redirected to something like
> http://localhost:8080/?wicket:interface=:13:1::: - which is a URL, not for
> the form, but for the specific version of the page that should be rendered.
>
We should copy/paste this into a Wiki page or something, Jeremy.
Thanks for taking the time to explain this in-depth for folks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: urls after a form submission
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Wed, Oct 6, 2010 at 8:43 PM, Alex Rass <ar...@itbsllc.com> wrote:
> But that breaks the common sense of "strategy", doesn't it?
> And if it works "special" for HybridUrlCodingStrategy, then it should also
> work with the other ones, right? "Consistency" rule makes it a bug, right?
>
Wrong. First, you have to understand what is happening behind the scenes.
Look at the URL that actually appears in your form's "action" attribute -
it is a full URL to a specific component, which will invoke the
IFormSubmitListener on that component (i.e.
../?wicket:interface=:13:loginForm::IFormSubmitListener::). After that form
is done processing, you are redirected to a URL to render whatever page is
supposed to be rendered. If you haven't specifically called
"setResponsePage(...)", then this means that Wicket hast re-render the page
that your form was on. BUT - it can't send you back to a bookmarkable URL
for that page (your pretty mount with query string parameters, etc), because
your form submission could have changed all kinds of state on the page, and
sending you to a bookmarkable URL will result in your page constructor
getting called and rendering a new page (without all of those state
changes). So, you must be redirected to the exact version of the page that
your form just modified. Thus, you are redirected to something like
http://localhost:8080/?wicket:interface=:13:1::: - which is a URL, not for
the form, but for the specific version of the page that should be rendered.
Now, to how HybridUrlCodingStrategy works.... It doesn't just encode URLs
for bookmarkable page requests (like QueryStringUrlCodingStrategy and others
do), but it also encodes URLs for redirect requests (those that happen after
form submits, etc....). This allows it to create a bookmarkable URL to
redirect to that also has the "13.1" in it (from the example URL above).
So, when that request comes in, it's recognized as a bookmarkable url
request, but HybridUCS also realizes that it has state version information
attached to it and tries to get that version out of the session. If it
exists, it operates exactly like the
http://localhost:8080/?wicket:interface=:13:1::: URL would, but if it
doesn't exist, it operates exactly like a bookmarkable page request would -
creating a new page.
> HybridUrlCodingStrategy messes with the original name. I'd rather use
> QueryStringUrlCodingStrategy that keeps urls proper.
I have no idea what you mean when you say it "messes with the original
name". Nor do I understand "keeps urls proper" since "proper" is
subjective. I'm assuming you mean "proper" as in "like URLs always used to
be - with question marks and ampersands".
> It's "almost" there
> with using wicket parameter, shouldn't it be fully compliant with the
> strategy of the parent? It just makes sense (to me).
>
What you're missing (and hopefully is very adequately explained above), is
that there are actually three different kinds of requests, and your strategy
is only handling one of them:
1. bookmarkable page request (like /site/page.html?foo=1&bar=2) - the
QueryStringUCS is handling this one. It's the one that originally renders
the page
2. IFormSubmitListener request (like
../?wicket:interface=:13:loginForm::IFormSubmitListener::) - this is where
the form actually gets submitted. That first "13" is the page ID -
basically a counter in your session that means this form was on the 14th
page created in your session (zero indexed). The "loginForm" (which could
easily be "somePanel:someList:0:someForm") is a full path to the component
that this URL needs to invoke some method on. So, from the 14th page in
session, get the "loginForm" component. The last part,
"IFormSubmitListener", indicates what method to call on the form, which is
onFormSubmitted (which does all the form processing and then calls onSubmit
or onError on your actual form object. This URL is not changed by either
HybridUCS or QueryStringUCS.
3. IRedirectListener (like ?wicket:interface=:13:1::: by default) - this
is where you are being redirected to the second version (0, then 1) of the
14th page in session. Your QueryStringUCS is not encoding this URL, but the
HybridUCS is to give it its functionality (see the javadocs for this class
as well).
Hope this helps.
--
Jeremy Thomerson
http://www.wickettraining.com
RE: urls after a form submission
Posted by Alex Rass <ar...@itbsllc.com>.
But that breaks the common sense of "strategy", doesn't it?
And if it works "special" for HybridUrlCodingStrategy, then it should also
work with the other ones, right? "Consistency" rule makes it a bug, right?
HybridUrlCodingStrategy messes with the original name. I'd rather use
QueryStringUrlCodingStrategy that keeps urls proper. It's "almost" there
with using wicket parameter, shouldn't it be fully compliant with the
strategy of the parent? It just makes sense (to me).
- Alex
-----Original Message-----
From: Jeremy Thomerson [mailto:jeremy@wickettraining.com]
Sent: Wednesday, October 06, 2010 8:13 PM
To: users@wicket.apache.org
Subject: Re: urls after a form submission
On Wed, Oct 6, 2010 at 6:59 PM, Alex Rass <ar...@itbsllc.com> wrote:
> Hi.
>
> After an on-page (wicket) form is submitted, the followed url doesn't
> follow the page's URL encoding strategy (QueryStringUrlCodingStrategy
> or any others).
>
> It just becomes "http://site.com/?wicket..." and loses original page
>
> Could someone please tell me if there's a way to fix it easily?
> Is this a bug that should be fixed or a normal behavior?
>
> I REALLY need this working. Otherwise a 200 page site becomes a class
> nightmare.
>
> - Alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
It's standard behavior. You're redirecting to a stateful page - with the
state of the form - when you submit the form. If you want a bookmarkable
URL that still has state, use HybridUrlCodingStrategy.
--
Jeremy Thomerson
http://www.wickettraining.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: urls after a form submission
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Wed, Oct 6, 2010 at 6:59 PM, Alex Rass <ar...@itbsllc.com> wrote:
> Hi.
>
> After an on-page (wicket) form is submitted, the followed url doesn't
> follow
> the page's URL encoding strategy (QueryStringUrlCodingStrategy or any
> others).
>
> It just becomes "http://site.com/?wicket..." and loses original page
>
> Could someone please tell me if there's a way to fix it easily?
> Is this a bug that should be fixed or a normal behavior?
>
> I REALLY need this working. Otherwise a 200 page site becomes a class
> nightmare.
>
> - Alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
It's standard behavior. You're redirecting to a stateful page - with the
state of the form - when you submit the form. If you want a bookmarkable
URL that still has state, use HybridUrlCodingStrategy.
--
Jeremy Thomerson
http://www.wickettraining.com