Just to be pedantic they are not ignored:
with "public getXXX" and "private setXXX" the property is read only
with "public getXXX" and "no setXXX" the property is read only
with "no getXXX" and "public setXXX" property is read and write




Matej Knopp-2 wrote:
> 
> Well, the private acessing functionality was mostly build with situation
> like
> 
> private String myField;
> 
> new PropertyModel(this, "myField");
> 
> i.e. without the setters and getters functionality. But I don't see
> reason why should getters and setters be ignored, even if they are
> private. Johan?
> 
> -Matej
> 
> On 8/24/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>>
>> Thanks again Matej,
>>
>> At first I just made my setValue method private. I had to remove getValue
>> to
>> make PropertyModel access the private member. Not sure I'm keen on this
>> behaviour. We have a long weekend here in the UK so I can ponder it
>> slowly.
>> Realised I've been avoiding implementing something because I can't think
>> of
>> a good property name and I don't want to have to fix it in my bean,
>> component java and component html... Maybe I will go with the verbose
>> solution. May also stop me pushing lots of rubbish into the model.
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > It's not out of date. PropertyModel provides access to privdate
>> > properties and it is completely intetional. The reason is actually to
>> > provide better encapsulation, because if you e.g. bind your component
>> > to a property of that component, you don't have to provide public
>> > setters and getters for that property (thus it can't be changed
>> > outside the component).
>> >
>> > -Matej
>> >
>> > On 8/24/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Thanks Matej,
>> >>
>> >> Is this
>> >>
>> http://wicketstuff.org/wicket13doc/org/apache/wicket/model/PropertyModel.html
>> >> PropertyModel  javadoc out of date where it says that "Note that the
>> >> property resolver by default provides access to private members and
>> >> methods.
>> >> If guaranteeing encapsulation of the target objects is a big concern,
>> you
>> >> should consider using an alternative implementation." out of date? I'm
>> >> glad
>> >> to say it doesn't seem to be true in 1.3.0-beta2
>> >>
>> >>
>> >>
>> >> Matej Knopp-2 wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > there's nothing wrong with yor approach, actually, it's more solid
>> >> > than using (Compound)PropertyModel because you get full refactoring
>> >> > support. The downside is of course code verbosity. Unless java get
>> >> > property expression there's not much we can do about it though :-/
>> >> >
>> >> > -Matej
>> >> >
>> >> > On 8/24/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> Does anybody use any other data binding than the built in Wicket
>> >> classes?
>> >> >>
>> >> >> We have few complex objects rather than lots of objects with lots
>> of
>> >> >> fields
>> >> >> so having the binding more explicit e.g.:
>> >> >>         add(new TextField("value", new ModelString() {
>> >> >>                                 public void setString(String p) {
>> >> >>                                         model.setValue(p);
>> >> >>                                 }
>> >> >>                                 public String getString() {
>> >> >>                                         return model.getValue();
>> >> >>                                 }
>> >> >>                         }));
>> >> >> Is tempting as we would get more tool support in eclipse etc and it
>> is
>> >> >> more
>> >> >> obvious what is going on. Obviously the huge downside is that it is
>> >> much
>> >> >> more verbose than:
>> >> >>     add(new TextField("value"));
>> >> >>
>> >> >> Sorry I'm being so greedy on this forum. Still not switched my
>> >> thinking
>> >> >> from
>> >> >> the two extremes of struts and GWT.
>> >> >>
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12310156
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >> >>
>> >> >>
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > 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#a12312105
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > 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#a12312628
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> ---------------------------------------------------------------------
> 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#a12312942
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to