Re: [Wicket-develop] Copy on replace implemented...

[Johan Compagner]

are there model problems with this?  if the user inncocently creates BookEditPage, when this copy happens, the new page will no longer be editing the same book model.  we'd at least need to document this behavior.  furthermore, if the copying doesn't /always/ happen (it depends on what components they use), things could feel a bit inconsistent to the user.  sometimes it's the same page and sometimes its a copy.  is there some simple thing we can tell people here? Not true. It will edit the exact same book. Because those things should be detachable anyway so In the end they are editing the exact same thing. And if you really have to do it by hand then i know exactly what happens.. The developer will constuct an exact same page and components (very cumbersum) and then also edit that same book (not by using the same model but by using the same id in the model) In the end the result is equal only how to get there is so much more work. but what if it's not detachable?  do you think should we stop supporting regular models and only have AbstractDetachableModel? If they are not detachable then they are serializeable .............. That is the whole point! If they aren't then clustering doesn't work, The webcontainer can't store the session to disk. Look at the logging of tomcat and you will see lots of errors in the log... And again make it an option that is default off then i don't see a problem. in terms of hibernate, jdo and other frameworks, is it going to be a problem to clone models like this? No why? Because those should use detachable models. Please remeber!! We use serialization that would also be used but clustering or by the webcontainer to dump the session on disk!!! So that should work then this should work also! There is no difference. obviously.  but again, what if the user has a regular old bean that's not detachable? Then that bean (and beans are) must be serializeable, Again this is a requirement, not by wicket but by a webcontainer. The webcontainer can also do these things. For example if a session is not used for a while it could dump it to disk, And when it is suddenly needed again it will it read in. These are the things a webcontainer can do. also, detaching a model like the code below could be really expensive because reattaching might involve a database query, for example.  should we even detach the model?  if we don't is hibernate going to be happy?  i suspect the answer is that we don't need to do the detach, actually.  isn't hibernate designed to deal with this? We need to detach. There is no other way. Because only deattached models are ready for serialization. actually, you /can/ serialize non-detachable models. No. Because we can't require that from a user. That is the whole point of detachable models. They are serializeable in a detached state but doesn't have to be in a attached state. i don't find stale pages acceptable in anycase. Can never happen. Should never happen. back buttons should always work work (2 deep not much more) I currently never call invalidateModel..(now called modelChanged) Becaus that makes the page stale.. unacceptable. but stale pages /do/ happen.  if you delete the only row from a list of fields and then hit back, the model is now an empty list.  what is that previous page supposed to do when you hit back, edit the field and submit your change?  there's no entry in the model to edit.  the page is stale because the model changed. one way you could fix this would be by not having detachable models!  then each page has its own independent model.  when you hit back, you'd go back to a page editing the model that was attached to that page.  i'm not suggesting this is the right thing, but it would "solve" the problem. 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. detachable models are essentially shared because they are backed by some store like a db.  if you have detachable models, you have stale pages because the state is shared!  when one page changes the state, the other pages have to go stale.  this is what tapestry does and it's what we have in wicket now. like it or not, stale pages are a fact of life if you're in a multi-user environment or you have shared models like detachable models. 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()) We should really strive for 100% back button prove in every possible way. agree that back button should work as much as possible.  but it can't always work because the structure of the old page may no longer match the structure of the model it's editing.  at some point, you have to give up and show the user an error. as i said just a matter of design. For example you delete: I have a list with 10 values Then I Don't delete one of them but i click on 7. I get an error because object is deleted because anohter users already deleted that object under my noise. So the page was already stale in youre eyes even i didn't do anything , i just rendered it. So i find staleness with delete examples not relevant You need to do this youre self anyway on those kind of lists. Because they could be changed/deleted by from any other place anyway. So i hope you get my point a bit. Staleness is a fact of live you it can happen at any time in any place even without youre doing right after you rendered youre page. So the developer should take that into account when designing the pages. So no i still don't like setting pages to stale.  I don't want that to happen. By the way i find modelChanged behaviour very strange by the way. In my swing experience this will not 'destroy' the components but let the components know that they should reaquire the model for its data because the model's data is changed. I would prefer to rename that method to what it really does: setPageState(); (or something like that) what the component /does/ on modelChanged is an implementation detail of the component.  the method is named based on is use not its implementation.  i think it's aptly named. yes i know but by default it sets the staleness. how change unexcepectedly? that shouldn't happen: model.deatach() model.atach() model should be completely equal then right before detach(). some other thread/session can modify the database.  i'm just pointing out that detach() opens a window of opportunity for these errors to come up.  i think it's a problem regardless though since we always detach() at the end of rendering so session sync can be lighter weight.  so it's a problem, but not anything we can fix generically. You should always use the latest object from the database. So the attach is a much better way anyway, because holding hibernate references over multipply request is a bad thing anyway, because they aren't attached anymore to a transaction. And for models that just has an id stored this is not relevant at all. (just the same hibernate object but then completely fresh again is queried) I agree for list. Those suddenly can have another entry (or lost an entry) a slightly different order ect.. But replace/removeall are called in the 'action' fase, not in the rendering. So developers should just take this into account. I think that if you have a link to set another tab. That almost all the models are still detached. Because in the component listener fase i don't think the data is asked from the models. It is another store by remove all. But then the models should be required anyhow.. It will only happen once in a request.. Never anymore. So if somehow 2 times in a same request a tabpanel is reset or removeALL is called then only the first time the 'clone' is happening. right.  because of the render count reset, right? yes Of course we could  drop down the wantPageCloned to Page that is just fine. but isn't it the component that wants the page cloned? not it is the developer ;) The container is the trigger of the clone/copy Because a container has the 2 methods: removeAll and replace..   finally, maybe we should consider keeping the current stale-detection functionality via an ApplicationSetting and have the option default to this (hopefully) idiot-proof transparent copying thing...  that way things work more often, but users who would rather not pay the cost of serialization OR deal with pagefactory could get the current functionality.  i think this might be worth saving.  we may get a lot of criticism over the performance of cloning via serialization. thoughts?  replies? one thing more. I am searching for a better serialization for use in the same JVM. It must be much faster if the ObjectOutputstream knows that it doesn't have to store any class meta data ect. that it only have to dump the instance data nothing more. Anybody knows a bit optimized java serialization implementation? i'm not sure i understand.  what's an example of class meta data that's being written out by serialization that you could omit?  what would you write out in its place? i think serialization is pretty much going to be greviously slow.  if there was a way to make it significantly faster, wouldn't someone have done that already? read this: http://www.javaworld.com/javaworld/javaqa/2003-01/02-qa-0124-clone-p3.html quote: "What's even worse, ObjectOutputStream and ObjectInputStream perform a lot of unnecessary work. For example, writing out class metadata (class name, field names, metadata checksum, etc.) that may need to be reconciled with a different class version on the receiving end is pure overhead when you serialize a class within the same ClassLoader namespace." And we don't need that also. We just need the simplest dump of the fields. If pages/components/models wheren't being extened ;) it would be much easier to gain speed, just use Externalizeable..... johan