What misses is what actually causes the problems in the first place: the
reachability of components. We want components to be reachable even
though they were replaced or removed from the current rendering of the
page, but that were there on a previous rendering. We don't allways want
that. But we want to be able to.
Eelco
Martijn Dashorst wrote:
Reading Jonathans posts, I am getting convinced that the undo
mechanism is _NOT_ the way to go. It does not solve the real problem.
I think we *really* need to get back to what exactly is the problem,
before we discuss solutions. Otherwise we will keep having the 'I
say/you say' discussions for the next several months.
My throw at the problem at hand:
- we have models and components
- the components are generated using the data from the models
- after the components are rendered, the model changes in such a way
that the components will not be representing the actual model anymore
when the user returns to the page without resubmitting the data (i.e.
press the back button)
- currently Wicket shows a 'stale data' error message when the data is
submitted again.
- the 'stale data' error message is something we don't want.
Anything I left out? Any discrepancies?
Martijn
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
