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]
