[
https://issues.apache.org/jira/browse/WICKET-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-3589.
-------------------------------------
Resolution: Won't Fix
This is the intended behavior.
You example is a bit simple and doesn't show the actual problems that may arise
without the renderCount check.
Imagine you have a repeater in the page with a link for each entry. Clicking on
the link manipulates somehow the associated entry. Wicket finds the component
behavior by its path, i.e. the path looks like "I'm a link in the nth entry in
a repeater which is in panel ...". The important part here is 'nth'. If you
manipulate the hierarchy in the second tab (e.g. add some entries, delete
others) and then try to edit/delete an entry in the first tab then with your
suggestion no one knows which entry will be edited/deleted because their order
is already modified by the actions in the second
tab.
With the current behavior of renderCount you will see the new state of the page
(which will be the same as in tab2) and then you may re-try to make the
intended modification safely.
> Request from a stale page does not perform intended action
> ----------------------------------------------------------
>
> Key: WICKET-3589
> URL: https://issues.apache.org/jira/browse/WICKET-3589
> Project: Wicket
> Issue Type: Bug
> Affects Versions: 1.5-RC2
> Environment: local
> Reporter: Nazaret Kazarian
> Attachments: reproduce-issue.zip
>
>
> Attached is a quickstart demonstrating the issue. Steps to reproduce:
> Fire the application in a browser (http://localhost:8080/reproduce-issue).
> Press "increment counter" a few times, say until the counter reaches 5. Now
> open a new browser tab and goto url http://localhost:8080/reproduce-issue/?0
> This will bring the same page with the correct state. You can see the counter
> is 5. Now press "increment counter" a few times on the new tab, say until the
> counter reaches 10. Now go back to the previous tab. The counter is of course
> still 5. Now press "increment counter" on this tab. I would expect the action
> to be executed and the counter to reach 11. In fact, this is the behavior on
> wicket version 1.4.16. Instead, on 1.5-rc2, the action is not executed and
> the page just refreshes to the current state, that is the counter shows 10.
> The same exact behavior can be seen using an ajax action as well.
> Is this the expected behavior on wicket 1.5? I would think that the way 1.4
> works seems more reasonable.
> Thanks a lot
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
