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?


Like said in an earlier mail... you will keep on working with the current page, so the exact same models are used, while the copied models are stored in the session. In theory, when people depend on hashcodes for identity this just might give problems when the back button is used. Though I can't thank of any real problems to be honest.




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?


Especially in the case of frameworks like Hibernate this wouldn't be a problem. Object identity is generally done by assigning objects an id. The hashcode of those objects is used internally by Hibernate to look at whether and object was allready loaded in the same session. Now, as a Hibernate session should allways only span one request, as you never know in what thread the next request will (and if there will be any at all), you should either decouple those objects from the Hibernate session, in which case there is no problem as the objects with the different hashcodes will have the same Hibernate identity, or - in case you want to load/update/etc. within one session - you use detached models.


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, the models do not have to be detached, as the pattern should be that all temporary data is marked transient. FYI, I allready removed the detaching of the models.

Eelco


------------------------------------------------------- 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

Reply via email to