as chris and i have both been trying to emphasize, we don't live in a hibernate world. there are legitimate reasons to use wicket with other kinds of models. as far as wicket is concerned, i think there should only be markup and models whose implementation details we know nothing about. how wicket's models are organized, persisted or reconciled with changes in a multi-user environment is very far out of wicket's scope. given that wicket is model-neutral, i think staleness detection is a useful feature. if you'd like a way of turning it off because you want to take over staleness detection yourself, i'm good with that and i agree that you should be able to solve all these problems by hand (and without cloning). but that's a lot of work for many people who are not working in exactly the mode you are working in. and i personally want to improve and use staleness detection because it solves a problem that is in wicket's domain, namely the case when markup and model get out of sync (again, this is a fundamental problem of browsers and back buttons that has nothing to do with model implementation). besides making staleness detection smarter, i'd like to make it easier to customize what happens when staleness is detected. that would solve at least part of your problem right there.
the good thing about this conversation is that we've come up with several ways to improve staleness detection:
1. make it smarter 2. make it easy to customize what happens when staleness is detected 3. make it possible to turn it off
how's that sound?
jon
Johan Compagner wrote:
No not stale in my eyes
The page should still work. Only the click on the link that is deleted would throw an error. A click on a link below it should do the job just fine.
But i know this is pretty hard. But thats what people are used to.
you missed my point. it's not a link. it's a textfield. and there's only one. the user goes back to the page with the textfield /that is no longer attached to any model!!!/. when they submit their change, the list is empty []. what are you going to do other than say "the page is stale" in some way?
Now i would say... You are missing the point
That is why i want this feature to work in my webbapp.
Because the model is still there. removeAll first makes a copy of the current page (so ListView)
And going back with the back button and then press submit again does work fine...
And i still don't want wicket to say: Page is stale go to home page.
What the webapp should do is what the developer says it should do.
So if a developer notice a submit on something that isn't there anymore in pageX it can redirect it to pageY with a feedback...
if you've got multiple rows like you're suggesting, you've got the same potential for damage. even if you sort the rows, you do. because the model and the page markup don't match and the page markup contains a mutator.
No that the case in my webbapps
the ListItem of a ListView has always the ID of the hibernate object. With that everything it does first goes through hibernate the load the right object from db (or cache)
then everything in the listiteme can go on.
So if the model did change (can happen always form any source,, see my previous mail)
The list item still has the right state (the hibernate id) It always works on the right one where i made him for.
This is in my eyes the only right way to do it
You can't use index (to the main model of the ListView) because when you click on something the index can point to another object.
Holding the completey hibernate object in the ListItem is also a bad idea.
The big problem is that models can change between 2 pages views without the current user doing anything...
Therefor you can only give a listitem as much state from the main model at construction time.
The problem is that yes the row that is deleted that link that is stale
The rest should work in my eyes. Why does this work when for example using struts? (i know why)
But this is also doable in wicket. It is just how you design youre ListView. (and not calling modelChanged())
no. you /do/ call modelStructureChanged(). wicket just needs to be smarter about staleness detection. for each form, we look at models that changed on that form and determine if any mutators are involved.
No don't agree wicket can never no that i don't see how Developers responsibility.
again, this component is not a mutator. the problem of staleness has to do with components that /edit data/. we need to examine if/how we can close down the scope of staleness detection so it doesn't include harmlessly stale data.
Then we need a list what hamfull and harmless is..
because showing a form with textfiels of a object that already is deleted.
Yes that is stale. you are right
But who is responsibel of handling that staleness? Wicket of the Developer?
I as a developer want to control that. For example:
List of users is page1 Edit of userX is page2
But userX is deleted so page2 is stale (completely)
That is something i want to know as developer so when that happens i want to redirect it to page1. (userlist)
johan
------------------------------------------------------- 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
