You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Chris Colman <ch...@stepaheadsoftware.com> on 2012/01/19 02:39:23 UTC
Best practice for returning to calling page after submitting a form page
I often use modal forms/dialogs so this issue is not a problem: In a
modal scenario when the user submits a modal the page they called the
modal form from is just sitting there behind the form when it closes -
no need for redirection to the 'calling page' as it's redundant.
In scenarios where some customers prefer not to have modal forms the
forms have to be pages in their own right and involve the 'browser page
change' dance.
Is there a best practice in Wicket for making reusable page forms that
remember which page called them and return to that page after submit or
cancel? Or is there a Wicket class that manages this?
Example scenario for Reusable Address form
Scenario 1
Page A shows supplier's data with a panel displaying their address which
includes a 'Change' button.
User clicks change and is taken to Address form page.
User makes changes and hits ok. The browser returns to page A.
Scenario 2
Page B shows customer's data with a panel display their address which
includes a 'Change' button.
User clicks change and is taken to Address form page.
User makes changes and hits ok. The browser returns to page B.
Yours sincerely,
Chris Colman
Pagebloom Team Leader,
Step Ahead Software
pagebloom - your business & your website growing together
Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120
Email: chrisc@stepahead.com.au <ma...@stepahead.com.au>
Website:
http://www.pagebloom.com <blocked::http://www.pagebloom.com/>
http://develop.stepaheadsoftware.com
<blocked::http://develop.stepaheadsoftware.com/>
Re: Best practice for returning to calling page after submitting a form page
Posted by Jeff Schneller <je...@mootus.com>.
You could make the address form have an abstract method to determine where to redirect to. In the form submit call the abstract method The the page constructor could take a param to tell which page to redirect to. Define the abstract method on the page to do the redirect based on the parameter passed to the page. Or you could have individual pages that all use the same address form.
On Jan 18, 2012, at 8:39 PM, "Chris Colman" <ch...@stepaheadsoftware.com> wrote:
> I often use modal forms/dialogs so this issue is not a problem: In a modal scenario when the user submits a modal the page they called the modal form from is just sitting there behind the form when it closes – no need for redirection to the ‘calling page’ as it’s redundant.
>
> In scenarios where some customers prefer not to have modal forms the forms have to be pages in their own right and involve the ‘browser page change’ dance.
>
> Is there a best practice in Wicket for making reusable page forms that remember which page called them and return to that page after submit or cancel? Or is there a Wicket class that manages this?
>
> Example scenario for Reusable Address form
>
> Scenario 1
>
> Page A shows supplier’s data with a panel displaying their address which includes a ‘Change’ button.
>
> User clicks change and is taken to Address form page.
>
> User makes changes and hits ok. The browser returns to page A.
>
> Scenario 2
>
> Page B shows customer’s data with a panel display their address which includes a ‘Change’ button.
>
> User clicks change and is taken to Address form page.
>
> User makes changes and hits ok. The browser returns to page B.
>
>
> Yours sincerely,
>
> Chris Colman
>
> Pagebloom Team Leader,
> Step Ahead Software
>
>
> pagebloom - your business & your website growing together
>
> Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120
> Email: chrisc@stepahead.com.au
> Website:
> http://www.pagebloom.com
> http://develop.stepaheadsoftware.com
>
>
Re: Best practice for returning to calling page after submitting a
form page
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Jan 19, 2012 at 6:54 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
>>You can pass PageReference to the page with the form and use it in
>>Form#onSubmit().
>>
>>Page1.java:
>>
>>setResponsePage(new FormPage(getPageReference()));
>>
>>FormPage.java:
>>
>>public FormPage(final PageReference pr) {
>>
>> add(new Form() {
>> onSubmit() {
>> setResponsePage(pr.getPage());
>> }
>> });
>>}
>
> PageReference looks nice. I hadn't noticed that class before. So it's a
> reference to a page instance in a page store?
>
> Will this just return the existing 'instance' of the page exactly the
> way it was before the user went to the form or will it use the page URL
> to perform a re-render and show any model updates that submitting the
> form may have caused?
It will get the previous (instance of the) page by id and show it.
If this page uses dynamic models the you are fine.
>
>>
>>
>>
>>On Thu, Jan 19, 2012 at 2:39 AM, Chris Colman
>><ch...@stepaheadsoftware.com>wrote:
>>
>>> ** **
>>>
>>> I often use modal forms/dialogs so this issue is not a problem: In a
>>modal
>>> scenario when the user submits a modal the page they called the modal
>>form
>>> from is just sitting there behind the form when it closes - no need
> for
>>> redirection to the 'calling page' as it's redundant.****
>>>
>>> ** **
>>>
>>> In scenarios where some customers prefer not to have modal forms the
>>forms
>>> have to be pages in their own right and involve the 'browser page
> change'
>>> dance.****
>>>
>>> ** **
>>>
>>> Is there a best practice in Wicket for making reusable page forms
> that
>>> remember which page called them and return to that page after submit
> or
>>> cancel? Or is there a Wicket class that manages this?****
>>>
>>> ** **
>>>
>>> Example scenario for Reusable Address form****
>>>
>>> ** **
>>>
>>> Scenario 1****
>>>
>>> ** **
>>>
>>> Page A shows supplier's data with a panel displaying their address
> which
>>> includes a 'Change' button.****
>>>
>>> ** **
>>>
>>> User clicks change and is taken to Address form page.****
>>>
>>> ** **
>>>
>>> User makes changes and hits ok. The browser returns to page A.****
>>>
>>> ** **
>>>
>>> Scenario 2****
>>>
>>> ** **
>>>
>>> Page B shows customer's data with a panel display their address which
>>> includes a 'Change' button.****
>>>
>>> ** **
>>>
>>> User clicks change and is taken to Address form page.****
>>>
>>> ** **
>>>
>>> User makes changes and hits ok. The browser returns to page B.****
>>>
>>> ****
>>>
>>> ** **
>>>
>>> Yours sincerely,****
>>>
>>> ** **
>>>
>>> Chris Colman****
>>>
>>> ****
>>>
>>> Pagebloom Team Leader,****
>>>
>>> Step Ahead Software
>>>
>>> ****
>>>
>>> pagebloom - your business & your website growing together****
>>>
>>> ** **
>>>
>>> **Sydney**: (+61 2) 9656 1278 ****Canberra****: (+61 2) 6100 2120
>>> ****
>>>
>>> Email: chrisc@stepahead.com.au <//...@stepahead.com.au>****
>>>
>>> Website:****
>>>
>>> http://www.pagebloom.com****
>>>
>>> http://develop.stepaheadsoftware.com****
>>>
>>> ****
>>>
>>> ** **
>>>
>>
>>
>>
>>--
>>Martin Grigorov
>>jWeekend
>>Training, Consulting, Development
>>http://jWeekend.com <http://jweekend.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Best practice for returning to calling page after submitting a form page
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>You can pass PageReference to the page with the form and use it in
>Form#onSubmit().
>
>Page1.java:
>
>setResponsePage(new FormPage(getPageReference()));
>
>FormPage.java:
>
>public FormPage(final PageReference pr) {
>
> add(new Form() {
> onSubmit() {
> setResponsePage(pr.getPage());
> }
> });
>}
PageReference looks nice. I hadn't noticed that class before. So it's a
reference to a page instance in a page store?
Will this just return the existing 'instance' of the page exactly the
way it was before the user went to the form or will it use the page URL
to perform a re-render and show any model updates that submitting the
form may have caused?
>
>
>
>On Thu, Jan 19, 2012 at 2:39 AM, Chris Colman
><ch...@stepaheadsoftware.com>wrote:
>
>> ** **
>>
>> I often use modal forms/dialogs so this issue is not a problem: In a
>modal
>> scenario when the user submits a modal the page they called the modal
>form
>> from is just sitting there behind the form when it closes - no need
for
>> redirection to the 'calling page' as it's redundant.****
>>
>> ** **
>>
>> In scenarios where some customers prefer not to have modal forms the
>forms
>> have to be pages in their own right and involve the 'browser page
change'
>> dance.****
>>
>> ** **
>>
>> Is there a best practice in Wicket for making reusable page forms
that
>> remember which page called them and return to that page after submit
or
>> cancel? Or is there a Wicket class that manages this?****
>>
>> ** **
>>
>> Example scenario for Reusable Address form****
>>
>> ** **
>>
>> Scenario 1****
>>
>> ** **
>>
>> Page A shows supplier's data with a panel displaying their address
which
>> includes a 'Change' button.****
>>
>> ** **
>>
>> User clicks change and is taken to Address form page.****
>>
>> ** **
>>
>> User makes changes and hits ok. The browser returns to page A.****
>>
>> ** **
>>
>> Scenario 2****
>>
>> ** **
>>
>> Page B shows customer's data with a panel display their address which
>> includes a 'Change' button.****
>>
>> ** **
>>
>> User clicks change and is taken to Address form page.****
>>
>> ** **
>>
>> User makes changes and hits ok. The browser returns to page B.****
>>
>> ****
>>
>> ** **
>>
>> Yours sincerely,****
>>
>> ** **
>>
>> Chris Colman****
>>
>> ****
>>
>> Pagebloom Team Leader,****
>>
>> Step Ahead Software
>>
>> ****
>>
>> pagebloom - your business & your website growing together****
>>
>> ** **
>>
>> **Sydney**: (+61 2) 9656 1278 ****Canberra****: (+61 2) 6100 2120
>> ****
>>
>> Email: chrisc@stepahead.com.au <//...@stepahead.com.au>****
>>
>> Website:****
>>
>> http://www.pagebloom.com****
>>
>> http://develop.stepaheadsoftware.com****
>>
>> ****
>>
>> ** **
>>
>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com <http://jweekend.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Best practice for returning to calling page after submitting a
form page
Posted by Martin Grigorov <mg...@apache.org>.
You can pass PageReference to the page with the form and use it in
Form#onSubmit().
Page1.java:
setResponsePage(new FormPage(getPageReference()));
FormPage.java:
public FormPage(final PageReference pr) {
add(new Form() {
onSubmit() {
setResponsePage(pr.getPage());
}
});
}
On Thu, Jan 19, 2012 at 2:39 AM, Chris Colman
<ch...@stepaheadsoftware.com>wrote:
> ** **
>
> I often use modal forms/dialogs so this issue is not a problem: In a modal
> scenario when the user submits a modal the page they called the modal form
> from is just sitting there behind the form when it closes – no need for
> redirection to the ‘calling page’ as it’s redundant.****
>
> ** **
>
> In scenarios where some customers prefer not to have modal forms the forms
> have to be pages in their own right and involve the ‘browser page change’
> dance.****
>
> ** **
>
> Is there a best practice in Wicket for making reusable page forms that
> remember which page called them and return to that page after submit or
> cancel? Or is there a Wicket class that manages this?****
>
> ** **
>
> Example scenario for Reusable Address form****
>
> ** **
>
> Scenario 1****
>
> ** **
>
> Page A shows supplier’s data with a panel displaying their address which
> includes a ‘Change’ button.****
>
> ** **
>
> User clicks change and is taken to Address form page.****
>
> ** **
>
> User makes changes and hits ok. The browser returns to page A.****
>
> ** **
>
> Scenario 2****
>
> ** **
>
> Page B shows customer’s data with a panel display their address which
> includes a ‘Change’ button.****
>
> ** **
>
> User clicks change and is taken to Address form page.****
>
> ** **
>
> User makes changes and hits ok. The browser returns to page B.****
>
> ****
>
> ** **
>
> Yours sincerely,****
>
> ** **
>
> Chris Colman****
>
> ****
>
> Pagebloom Team Leader,****
>
> Step Ahead Software
>
> ****
>
> pagebloom - your business & your website growing together****
>
> ** **
>
> **Sydney**: (+61 2) 9656 1278 ****Canberra****: (+61 2) 6100 2120
> ****
>
> Email: chrisc@stepahead.com.au <//...@stepahead.com.au>****
>
> Website:****
>
> http://www.pagebloom.com****
>
> http://develop.stepaheadsoftware.com****
>
> ****
>
> ** **
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>