Re: Re[2]: Alternative to Wicket data binding
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]
Re: Re[2]: Alternative to Wicket data binding
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]
Re: Re[2]: Alternative to Wicket data binding
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]
Re: Re[2]: Alternative to Wicket data binding
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.
Having a more obscurely located PrivateFieldModel is exactly catering to
power
users, while minimizing the chance of abuse by newbies. So both newbies and
power users are catered to.
In fact, I am thinking about having an SelfPropertyModel instead which
will always try to access the properties and private fields of the model
itself. In the desired usage, one should create an anonymous subclass of
SelfPropertyModel that has the component as the enclosing instance,
SelfPropertyModel will work on that component too. Obviously the
constructor of SelfPropertyModel will only take the name of the property,
but not a object (nor another model), it will truly only work on itself, its
intended purpose will be clear and it can't be *easily* abused.
public class NamePanel extends Panel {
private String firstName;
private String lastName;
public NamePanel() {
add(new TextField(firstName, new SelfPropertyModel(firstName) {}));
...
}
}
igor.vaynberg wrote:
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
I am fine with it (even though I am learning more and more about this issue
in the process).
--
View this message in context:
http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12379273
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: Alternative to Wicket data binding
yeah, but you are forgetting that you will also need the compound variant,
blah blah. before you know it you have replicated a bunch of the hierarchy.
like i said, lets have a vote, propose as many variants of this as you want
and we can see where it goes/what people prefer.
-igor
On 8/28/07, Kent Tong [EMAIL PROTECTED] wrote:
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.
Having a more obscurely located PrivateFieldModel is exactly catering to
power
users, while minimizing the chance of abuse by newbies. So both newbies
and
power users are catered to.
In fact, I am thinking about having an SelfPropertyModel instead which
will always try to access the properties and private fields of the model
itself. In the desired usage, one should create an anonymous subclass of
SelfPropertyModel that has the component as the enclosing instance,
SelfPropertyModel will work on that component too. Obviously the
constructor of SelfPropertyModel will only take the name of the property,
but not a object (nor another model), it will truly only work on itself,
its
intended purpose will be clear and it can't be *easily* abused.
public class NamePanel extends Panel {
private String firstName;
private String lastName;
public NamePanel() {
add(new TextField(firstName, new SelfPropertyModel(firstName)
{}));
...
}
}
igor.vaynberg wrote:
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
I am fine with it (even though I am learning more and more about this
issue
in the process).
--
View this message in context:
http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12379273
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: Alternative to Wicket data binding
igor.vaynberg wrote: yeah, but you are forgetting that you will also need the compound variant, blah blah. before you know it you have replicated a bunch of the hierarchy. like i said, lets have a vote, propose as many variants of this as you want and we can see where it goes/what people prefer. Right. What if we have a SelfCompoundPropertyModel? It can serve as the middle man for access to the component's private fields. So in principle it is doable. -- View this message in context: http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12379505 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: Alternative to Wicket data binding
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 alliaskedjohantodowastotweakpropertyresolvertoallowaccessto privatestuff.iwasundertheimpressionthatthepropertyresolveralways triestoaccessthegetter/setterfirst,thenthefield. halfofthisthreadyouarearguingthatweshouldntallowaccesstoprivate fields/methodsandhalfofityouarearguingthatweshouldbuttrythe getterfirst,soimprettyconfused. No,again,I'marguingto*either*allowingaccesstoallprivate,or don'tallowitatall.Iamnotagainstprivatememberaccessperse, justwantittobeconsistent. Eelco - Tounsubscribe,e-mail:[EMAIL PROTECTED] Foradditionalcommands,e-mail:[EMAIL PROTECTED] -- , Olegmailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: Alternative to Wicket data binding
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]
