the processing impart would be nil because we cache a lot of the information. however forcing wicket annotations on middle tier objects is not a very good approach.
if people really wanted to do this they can create this kind of annotation themselves and then install a security manager that would check it. 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. -igor On 8/25/07, Oleg Taranenko <[EMAIL PROTECTED]> wrote: > > Hi Igor and Eelco, > > > Sorry, for interventing in your discussion :) > > > May java annotations can help us? > > > Say [EMAIL PROTECTED]/Write > > or [EMAIL PROTECTED] or ever to protect all bean. > > > It would protect the field from accidently access in Wicket models > > without any assumption on set/get functions. > > > How it lead to additional lag on processing the model, i can't estimate. > > > Cheers, > > > Oleg > > > > > >> all i asked johan to do was to tweak property resolver to allow access to > > > >> private stuff. i was under the impression that the property resolver always > > >> tries to access the getter/setter first, then the field. > > > > >> half of this thread you are arguing that we shouldnt allow access to > >> private > > > >> fields/methods and half of it you are arguing that we should but try the > > >> getter first, so im pretty confused. > > > > No, again, I'm arguing to *either* allowing access to all private, or > > > don't allow it at all. I am not against private member access per se, > > > just want it to be consistent. > > > > Eelco > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- > > С уважением, > > Oleg mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]> > --------------------------------------------------------------------- To > unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED]
