Re: urls after a form submission
On Wed, Oct 6, 2010 at 10:38 PM, Jeremy Thomerson jer...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: urls after a form submission
On Wed, Oct 6, 2010 at 6:59 PM, Alex Rass a...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@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
RE: urls after a form submission
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:jer...@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 a...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: urls after a form submission
On Wed, Oct 6, 2010 at 8:43 PM, Alex Rass a...@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=1bar=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
