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.
yeah, i agree. i'm really attempting to work the problem at both ends and this is usually something i do offline. part of the problem is that i'm thinking aloud a lot. i can try to stop doing that if it would be more helpful. sometimes brainstorming just clouds the air...
anyway, yes, it would be a good time to really, thoroughly define our problem. we've definitely run in some circles today and we need to get this nailed down so everyone understands it.
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)
i think this beginning is correct.
however i think it's overstating things to say that the current implementation is /wholly/ "unsatisfactory". discovering stale pages like this is the same as what tapestry does and actually better than what echo does. i do, however, agree that a more complete solution is possible. which is what all the brainstorming is about. i personally work problems at both ends a lot because in the end, you can only define the problem as well as you can understand it, and part of understanding and defining a problem is to play with the parameters in mocking up solutions. the part we need to do, as you are suggesting, is start working the other end again now that we've learned something about the problem.
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?
i wouldn't think of it that way. it's not the component that's stale or the data model. really it's the /markup/ that's stale when compared with the current Page object. if you couldn't get back to the stale markup (which has "fallen behind" the component model), there wouldn't be a problem in the first place. so i think we can start by defining the problem at the most general level as this: "how do we deal with stale markup accessed with the browser back button?"
what we need to do is take a request from the markup that got rendered at time T1 and reconcile that request with the component hierarchy that exists at time T2. if the request /can/ be reconciled then it should succeed. if it cannot, then the model has changed too much for the request from stale markup to succeed. this is when a request is truly stale. and i think that's the best way to think about it. it's not even the stale html page that's the problem, it's /a given request coming from stale markup on that page/.
so what we're trying to do is reconcile a request that is coming from stale markup. the whole page may not be stale. it's just the piece of markup that's generating the request.
so to invent some terminology, let's call a request from a hunk of stale markup that doesn't match the /current/ component model a "stale request" just for brevity.
when we get a stale request, we need to figure out what component at time T2, if any, corresponds to the component that was around at T1 when the now-stale markup was generated.
do we all agree on the problem definition so far?
there's no point in going further if we don't see this much the same way.
make sense?
And if the data was altered in another session/external to the Wicket application? How would you do this?
this problem is outside the scope of wicket and has to do with model management and persistence (for example, hibernate can detect such changes).
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
------------------------------------------------------- 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
