i'm trying to mentally walk the line here between giving up on what johan wants and sharing the same worries you do. the only compromise i can see so far is this:
1. try to improve staleness detection, if possible. consider limiting staleness detection to forms with affected mutator components.
2. restrict cloning to uses of replace() only, ensuring that only then is cloning ever done.
3. put a warning on any component that uses replace() that the component will cause the page to be cloned and have a lengthy discussion in the same javadoc of what that will mean to the user
i've got to say that even though i'm looking for compromise (especially because that has been so productive on wicket to date!), my gut instinct is still that we should remove replace() and never clone anything. frankly cloning scares me anytime i see it.
Christopher Turner wrote:
> Youre bussiness object should be in a detachable model anyway.
> If the current implementation fails. Then also clustering fails. I don't see another way. This was a great
> serializeable test we fixed a few things.
>
I think you are wrong on this. There should be no requirement that my business object should be detachable. This forces me down a design direction that I may not wish to follow. There are some really genuine cases where I may want to create a business object that implements Serializable and that I wish to keep in the session. The hangman example does exactly this. It is also a common approach for non-mission critical things like shopping baskets, questionnaires, tax calculators and so on. Some applications (especially read-mostly) just don't need persistent storage in the background because the storing of business data in the session is significantly less that the overhead of keep writing it to/from a database for each request. In these cases detaching the model to a database is just not necessary. Thus I would want to use an ordinary model that contains a serializable business object. Any form of copy/clone would prevent this highly useful design pattern.
> So it is not the other way around clustering will fail because of this.
> And again i have stressed this in other post.
> If wicket doesn't support this, i as developer must do this all by hand, I already do this currently by a
> project. There i use a copy constructor and make
> a complete new page/components/models based on the current page/components/models. This is very hard work.
>
> People can turn it off (it is/can by default i don't care) Or people can make there own factory so that for some
> pages they are going the default way
> others they do it by there own code (copy constructor) and even others they don't do nothing...
>
That is my point. I think the use of any form of cloning or copy constructor, whether done manually by yourself or built into the framework is a poor design pattern. We should try to find another way to solve it imho.
> So difficutlties in clustering i really don't see. Because the end result is the same when i do it by hand or
> not.. exactly the same.
> johan
Regards, Chris
------------------------------------------------------- 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
