You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Makundi (JIRA)" <ji...@apache.org> on 2009/01/06 13:34:45 UTC
[jira] Created: (WICKET-2006) If FormTester is used twice or the
same WicketTester and an involved form is updated (new visible/invisible
components), the old form state prevails in tester
If FormTester is used twice or the same WicketTester and an involved form is updated (new visible/invisible components), the old form state prevails in tester
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: WICKET-2006
URL: https://issues.apache.org/jira/browse/WICKET-2006
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4-RC1
Environment: Any
Reporter: Martin Makundi
If FormTester is used twice or the same WicketTester and an involved form is updated (new visible/invisible components), the old form state prevails in tester.
Example:
[Login page, fields enabled]
Submit
[For some business logic reason, form is shown again but the fields are disabled]
Browser sees disabled fields. The form submitted via WicketTester sees enabled fields, i.e., the form processed by the wickettester is WRONG (wrong instance?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-2006) The page set by setReponsePage does
not process its own response.
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Johan Compagner closed WICKET-2006.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.4-RC2
1.3.6
Assignee: Johan Compagner (was: Matej Knopp)
fixed it so that page id's are always session specific so that they never overlap by accident
> The page set by setReponsePage does not process its own response.
> -----------------------------------------------------------------
>
> Key: WICKET-2006
> URL: https://issues.apache.org/jira/browse/WICKET-2006
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC1
> Environment: Any
> Reporter: Martin Makundi
> Assignee: Johan Compagner
> Fix For: 1.3.6, 1.4-RC2
>
> Attachments: Wicket-Quickstart.zip
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> Whenever the HomePage is submitted, it uses
> setResponsePage(new HomePage(xxx)); to open a new page in a new state.
> Whenever the form is submitted, the original page processes the form and thus any components that have changed state (e.g., become visible / invisible) remain in their original state and are not processed properly.
> More technically:
> The browser is viewing page instance X, but the form being processed belongs to the original page instance 0.
> It seems that the page set by setReponsePage does not process its own response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-2006) The page set by setReponsePage does
not process its own response.
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Johan Compagner reassigned WICKET-2006:
---------------------------------------
Assignee: Matej Knopp
This is because of your:
getSession().replaceSession();
call
You can change that in 2 ways
change the place where you call that so not at the beginning of the onsubmit but completely at the end:
// Return onto the same page but disable inputField
setResponsePage(new HomePage(false, ++submitCount));
getSession().replaceSession();
then it works fine
The other is setting this setting:
protected void init() {
super.init();
getSessionSettings().setPageIdUniquePerSession(true);
}
I still dont know why that is not default to true
I think we should just drop the complete pagemap page id.
and always just use the session to create the next page id that is unique across all sessions
Why do we have that setting? Matej was there really a thing that we still need the page pagemap id?
So the only good fix that is see is drop the pagemap page id generator completely
> The page set by setReponsePage does not process its own response.
> -----------------------------------------------------------------
>
> Key: WICKET-2006
> URL: https://issues.apache.org/jira/browse/WICKET-2006
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC1
> Environment: Any
> Reporter: Martin Makundi
> Assignee: Matej Knopp
> Attachments: Wicket-Quickstart.zip
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> Whenever the HomePage is submitted, it uses
> setResponsePage(new HomePage(xxx)); to open a new page in a new state.
> Whenever the form is submitted, the original page processes the form and thus any components that have changed state (e.g., become visible / invisible) remain in their original state and are not processed properly.
> More technically:
> The browser is viewing page instance X, but the form being processed belongs to the original page instance 0.
> It seems that the page set by setReponsePage does not process its own response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2006) The page set by setReponsePage does
not process its own response.
Posted by "Martin Makundi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Makundi updated WICKET-2006:
-----------------------------------
Description:
Whenever the HomePage is submitted, it uses
setResponsePage(new HomePage(xxx)); to open a new page in a new state.
Whenever the form is submitted, the original page processes the form and thus any components that have changed state (e.g., become visible / invisible) remain in their original state and are not processed properly.
More technically:
The browser is viewing page instance X, but the form being processed belongs to the original page instance 0.
It seems that the page set by setReponsePage does not process its own response.
was:
If FormTester is used twice or the same WicketTester and an involved form is updated (new visible/invisible components), the old form state prevails in tester.
Example:
[Login page, fields enabled]
Submit
[For some business logic reason, form is shown again but the fields are disabled]
Browser sees disabled fields. The form submitted via WicketTester sees enabled fields, i.e., the form processed by the wickettester is WRONG (wrong instance?).
Summary: The page set by setReponsePage does not process its own response. (was: If FormTester is used twice or the same WicketTester and an involved form is updated (new visible/invisible components), the old form state prevails in tester)
> The page set by setReponsePage does not process its own response.
> -----------------------------------------------------------------
>
> Key: WICKET-2006
> URL: https://issues.apache.org/jira/browse/WICKET-2006
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC1
> Environment: Any
> Reporter: Martin Makundi
> Attachments: Wicket-Quickstart.zip
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> Whenever the HomePage is submitted, it uses
> setResponsePage(new HomePage(xxx)); to open a new page in a new state.
> Whenever the form is submitted, the original page processes the form and thus any components that have changed state (e.g., become visible / invisible) remain in their original state and are not processed properly.
> More technically:
> The browser is viewing page instance X, but the form being processed belongs to the original page instance 0.
> It seems that the page set by setReponsePage does not process its own response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2006) The page set by setReponsePage does
not process its own response.
Posted by "Martin Makundi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Makundi updated WICKET-2006:
-----------------------------------
Attachment: Wicket-Quickstart.zip
A wicket quickstart for easily repeating the problem.
Press the form submit button once, and you will get a form with the input field disabled. You would assume pressing the button again, the page instance set in the "setResponsePage" method would process the form but NO, it is the original (first) page which will process the form.. not knowing you have edisabled the field and any other problems that might result ..
> The page set by setReponsePage does not process its own response.
> -----------------------------------------------------------------
>
> Key: WICKET-2006
> URL: https://issues.apache.org/jira/browse/WICKET-2006
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC1
> Environment: Any
> Reporter: Martin Makundi
> Attachments: Wicket-Quickstart.zip
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> Whenever the HomePage is submitted, it uses
> setResponsePage(new HomePage(xxx)); to open a new page in a new state.
> Whenever the form is submitted, the original page processes the form and thus any components that have changed state (e.g., become visible / invisible) remain in their original state and are not processed properly.
> More technically:
> The browser is viewing page instance X, but the form being processed belongs to the original page instance 0.
> It seems that the page set by setReponsePage does not process its own response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2006) The page set by setReponsePage does
not process its own response.
Posted by "Martin Makundi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Makundi updated WICKET-2006:
-----------------------------------
Comment: was deleted
> The page set by setReponsePage does not process its own response.
> -----------------------------------------------------------------
>
> Key: WICKET-2006
> URL: https://issues.apache.org/jira/browse/WICKET-2006
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC1
> Environment: Any
> Reporter: Martin Makundi
> Attachments: Wicket-Quickstart.zip
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> Whenever the HomePage is submitted, it uses
> setResponsePage(new HomePage(xxx)); to open a new page in a new state.
> Whenever the form is submitted, the original page processes the form and thus any components that have changed state (e.g., become visible / invisible) remain in their original state and are not processed properly.
> More technically:
> The browser is viewing page instance X, but the form being processed belongs to the original page instance 0.
> It seems that the page set by setReponsePage does not process its own response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2006) If FormTester is used twice or the
same WicketTester and an involved form is updated (new visible/invisible
components), the old form state prevails in tester
Posted by "Martin Makundi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Makundi updated WICKET-2006:
-----------------------------------
Attachment: Wicket-Quickstart.zip
Quickstart for easily repeating the problem.
> If FormTester is used twice or the same WicketTester and an involved form is updated (new visible/invisible components), the old form state prevails in tester
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-2006
> URL: https://issues.apache.org/jira/browse/WICKET-2006
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC1
> Environment: Any
> Reporter: Martin Makundi
> Attachments: Wicket-Quickstart.zip
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> If FormTester is used twice or the same WicketTester and an involved form is updated (new visible/invisible components), the old form state prevails in tester.
> Example:
> [Login page, fields enabled]
> Submit
> [For some business logic reason, form is shown again but the fields are disabled]
> Browser sees disabled fields. The form submitted via WicketTester sees enabled fields, i.e., the form processed by the wickettester is WRONG (wrong instance?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2006) The page set by setReponsePage does
not process its own response.
Posted by "Martin Makundi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Makundi updated WICKET-2006:
-----------------------------------
Attachment: (was: Wicket-Quickstart.zip)
> The page set by setReponsePage does not process its own response.
> -----------------------------------------------------------------
>
> Key: WICKET-2006
> URL: https://issues.apache.org/jira/browse/WICKET-2006
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC1
> Environment: Any
> Reporter: Martin Makundi
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> Whenever the HomePage is submitted, it uses
> setResponsePage(new HomePage(xxx)); to open a new page in a new state.
> Whenever the form is submitted, the original page processes the form and thus any components that have changed state (e.g., become visible / invisible) remain in their original state and are not processed properly.
> More technically:
> The browser is viewing page instance X, but the form being processed belongs to the original page instance 0.
> It seems that the page set by setReponsePage does not process its own response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.