Perhaps to keep us newbies happy a pointer in the javadoc to what to do if you want vanilla Java Bean behaviour might be handy. I just pulled a face and put it on my todo list to change.
Anyway, I still can't decide between the verbose solution with tool support and concise magic without tool support. Will make my tech lead decide, that is what he gets the big money for :) igor.vaynberg wrote: > > cmon, there are plenty of things you can abuse in wicket, or any other > framework. that is just the nature of the beast. as framework developers > we > put out features and hope that our users know how to use them responsibly. > we cannot continuously cater to newbie users, we have to cater to power > users as well - and that sometimes means making things that newbie users > might think unclean available anyways so power users can use them easily. > having two property models might work but it just adds clutter. > > we are going about this in circles, so what i propose is that someone who > really cares about this to put out a vote. > > -igor > > > On 8/28/07, Kent Tong <[EMAIL PROTECTED]> wrote: >> >> >> >> 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] >> >> > > -- View this message in context: http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12381449 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
