Jonathan Locke wrote:
it could be that i'm off in a ditch. that happens occasionally.
but i suspect that you are not quite understanding what i'm saying.
That is why I think we really need to get the problem clear before we start discussing options. I think we have a meta problem here and that is that each and everyone of us is trying to *solve* their understanding of the problem, rather than solving the actual problem. From the discussion until now I couldn't get a clear understanding what exactly we are trying to solve. I only saw solutions and objections to those solutions without an end in the near future (next 2-3 months).
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.
how does it not solve the real problem? what is the real problem?
Like I said, I don't know what the real problem is, and I gather neither does anyone of us. Until we have *CLEARLY* defined where something goes wrong, and what, we shouldn't be discussing solutions.
- the components are generated using the data from the models
yes, the components reference 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)
correct.
And now you go back to discussing a probable solution. This is not what I wanted:
Jonathan Locke wrote:
using the undo model, at the point when you return to that page, we ... SNIP ... less solved (i think more actually).
am i making sense here? if you re-read this paragraph and it doesn't make sense, maybe you could explain to me where you think i'm going wrong. thanks!
You are not making any sense, because I don't know what _exactly_ we are trying to solve.
Summarizing:
- the problem is the handling of a mismatch between the components and the model due to changes in the model that are not available to the rendered components when these components are used in some sort of action (submitting a form, clicking a link)
Analyzing this:
- we use the 'redirect after post' pattern to solve the obnoxious 'POSTDATA' message of browsers. Which is A Good Thing.
- this allows the user of the webapplication to click on the back button at will. This is also A Good Thing (eventhough we might think otherwise right now)
- when the browser returns to the page containing the old structure of components and the rendered, now obsolete, data, it would normally have done a POST
- we are missing this POST, otherwise we wouldn't have the 'stale data'
- it is somehow possible to determine that the model has changed, i.e. is stale, as to genereate an error message (current unsatisfactory implementation)
Questions:
- is the problem in rendering the page on which the user returns when pushing the back button? Or is it in any action taken after that? What is the exact timeline here?
- is it possible to detect for 100% sure that a component is associated with stale data? And if the data was altered in another session/external to the Wicket application? How would you do this?
I have probably more questions, but I'm too tired now to concentrate enough to mail them. Sorry bout that, but I wanted to send this anyway.
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
