Hello Igor, On 12/13/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > I did not put this strategy [ReuseIfModelObjectsEqualStrategy] in extensions > on purpose. > The reason being is that this can really get you in trouble when dealing with > detachable models. > Imagine changing a page and having all the model's from last page load as > well as all the models on this page. The idea behind ifmodelequals was that > when you compare detachable models you can just compare the database ids of > objects they point to instead of loading the objects from the db.
Well, maybe it's too late, but I don't really understand your example. Could you please give a concrete "scenario" to help me understand ? I couldn't use ReuseIfModelEqualsStrategy because I was working with value objects (objects with no identity, directly attached to the owning object so not directly reachable from a database call). And I also wanted to keep those objects as close as possible to their owning components, because my demo allows users to delete an object in the middle of the list, so I could not just store the position of the object in the list because when the list changes, the Component position in the list is not in sync with the list anymore (expected behaviour, but that prevents me from using the position in order to retrieve the model to compare ...). I have seen 3 solutions here: - don't store the position in the model (making it some sort of detachable model) but store the concrete object in a Model. (the solution I choosed) - don't directly modify the list model, but use a subclass of DataView in order to always keep Item position and list position in sync (needed to implement methods for adding, removing, replacing, switching Items). Interesting solution for all Form based lists. Developers just have to remind that, if they kept a reference to the model list, they are not allowed to alter it directly. - use "lazy" Models that are just keeping position of the object in the list when detached, but ensure that before the first change made to the list by anything, all the Items have their models attached in order for them to retrieve the right object at the right position, before list model changes. I think this could have been made by forcing users and already existing code to call DataView.modelChanging() before doing anything to the list model, thus giving a chance to the DataView component to initialize all the models of its items. No solution is perfect. I think the better one would be a mix between the 2 and the 3, but I currently implemented the 1 because it was so quick and easy. But now that you have a concrete example at hand, it is easier to show you where my problem is. Fiouuu, another quite long e-mail ! see you, -- laurent ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
