it may be obvious, but i just realized i want to refine even my small start to our problem definition.
after this:
"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."
i really meant to add
"and figure out how to execute the request, if possible, against the component that exists at T2"
so we get a request from markup that was generated at T1 and we need to service that request using the components that are available at T2.
i think the reason undo has been such a natural thing to discuss is that the concept attempts to reverse time and figure out what the page was like at T1 by starting at T2 and working backwards. this intuitively seems like a great idea because unlike cloning, undo accomplishes the same things cloning does but with more opportunity to control and incrementally record the changes. the more wicket can know about what happened between T1 and T2, the better. at least that's my very strong hunch. but let's not get diverted by this... ;-)
Jonathan Locke wrote:
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
------------------------------------------------------- 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
