igor.vaynberg wrote: > > i really dont think this is breaking encapsulation. i will concede that > there is one case where it can break encapsulation and that is when you > start out with what is publically accessible and then later you change > your > mind and make it completely private, but forget to remap the property > model. > it is a case where it is easy to make the mistake of not updating property > models. all other cases i believe are unimportant because you would have > to > go poke around the class to even know that private field is there to start > with.
I think the problem is that by allowing the default, core model in Wicket (PropertyModel) to access private fields, you're telling people that it is OK or even desirable to access private fields, while in fact, in your mind this power should only be exercised to *keep* encapsulation, instead of breaking it. For the moment many users don't know about this feature, so there is practically little impact on them. But once they learn about it, they will go ahead to access private fields even though the author of the class explicitly indicated that they shouldn't be accessed by not providing setters. Yes, those users can always access private fields using Java reflection. But they had to go through hops to do that. Now Wicket is telling them it is perfectly fine to do that and is making it super-easy to do. That makes a difference. Greater power comes with greater responsibility. The problem is it is easy to give people power but hard to make them realize the associated responsibility (when to use that feature). That's why I always suggest to have a PrivateFieldModel class (probably in Wicket extensions) extending PropertyModel to provide that extra power. Due to the non-default nature of PrivateFieldModel, only if one is clear about the responsibilities will he get to power. -- View this message in context: http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12364419 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
