i think that is a foolish argument as you are assuming property model should
only work on _beans_
it is perfectly normal to do something like this:
class data { public String name; public int age; }
and wicket should work with this. if this data object is a private inner of
something and is only used there wth is the point of creating
getters/setters?
so our property model should work like this:
always try setter/getter first, if not fallback onto the field.
i dont really see a danger of propertymodel accessing private members
because you can do it yourself if you wanted - and in fact you ARE doing it
yourself by specifying that property path.
-igor
On 8/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> On 8/25/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > But the binding is as pluggable as possible. You can write any IModel
> > implementation you want. Think of (Compound)PropertyModel as pure
> > convenience implementation (that works for 99% usecases). With wicket,
> you
> > don't think of mapping http requests to bean. But you have to think
> about
> > mapping components to beans, because that's a fundamental thing in
> wicket
> > (thus IModel).
> >
> > Anyway, I think if there is a public getter and private setter, we
> should
> > honor the private setter and don't touch the field directly.
>
> I think that choice is completely arbitrary. Why honor encapsulation
> when a setter is private but not when there is no setter?
>
> Look, just about two months ago I discovered property models could
> work on private fields directly. I wasn't crazy about that, but Igor
> made a point and convinced me that it is ok to have when you work on
> private members of components. Even though I don't see any danger in
> providing such components with getters and setters, it's mostly bloat,
> so I can live without that. Normal beans however, I'm not so sure now
> about those... I hate the fact that we're inconsistent now with what
> people would typically expect. Like it or not, java beans using
> getters and setters is an established pattern.
>
> Maybe we could do something in between. If the target of a property
> model is a component, the model can work on the member directly
> (should first try *any* setter and if none is available, use the
> field), but if the target is not, it should only work via getters and
> setters.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
