How does Wicket handle stale data and the back button?
Because Wicket has a first class component object model where the state for every page and nested component is available in the user’s session, it can trace through all that state when model information changes looking for pages containing components with models that have changed in ways that invalidate earlier renderings of those components and pages. This provides automatic handling for the back button, which has to do with stale markup, and can generally be divorced from the typical problems of stale data in a multi-user environment, which should be handled with the usual (optimistic) locking techniques in the persistence layer. A good example of stale markup is this: If a table on a page is rendered when there are 20 rows in the table’s model, a subsequent deletion of a row will invalidate the rendering of the table that is still cached in the user’s browser. When the user accesses the 20th row in the cached page by using their back button, the link will not be backed correctly. Wh
