FWIW: You guys probably already thought of this, but you can short circuit
this by using a field naming convention different from the property naming
convention... like "_field"
Clinton
On Sun, Sep 6, 2009 at 10:36 AM, Brandon Goodin <brandon.goo...@gmail.com>wrote:
> Forget the JavaBean spec and provide column to method mapping :) Then you
> could intentionally map a column to a "set" method on a class if you wanted.
> Of course you may open a can of worms with that since some people may want
> to pass multiple columns to a method. But, then again, that's not much
> different than the new constructor functionality.
> Just my lame .02
>
> Brandon
>
>
>
> On Sun, Sep 6, 2009 at 8:46 AM, <carlosjosep...@gmail.com> wrote:
>
>> I'm all for field access! Or a default field-then-property. I'm also
>> fond of the syntax prop.(field) that you came out with time before in
>> the list, but again reversing the default (prop).field.
>>
>> Best regards
>> --
>> Carlos
>>
>>
>> On Sun, Sep 06, 2009 at 01:23:18AM -0600, Clinton Begin wrote:
>> > I'm almost sad that I ever supported JavaBeans properties... fields
>> would
>> > have been so much better. I wonder if it's too late to make that
>> call...
>> >
>> > Does anyone actually care if iBATIS uses getter/setters instead of
>> fields
>> > directly?
>> >
>> > The only case I can think of is for "calculate on set" type logic in
>> > JavaBeans classes (where it calculates a number of other properties
>> based on
>> > setting one).
>> >
>> > Cheers,
>> > Clinton
>> >
>> > On Mon, Aug 31, 2009 at 3:17 PM, Carlos Pita <carlosjosep...@gmail.com
>> >wrote:
>> >
>> > > Hi all,
>> > >
>> > > I'm porting an application persistence layer from hibernate to ibatis.
>> > > The hibernate implementation uses field access, and changing to
>> > > property access will be asking for trouble at this point of
>> > > development. I know ibatis already fallbacks to field access when
>> > > there is no property getter/setter, but I yearn for the inverse
>> > > resolution order.
>> > >
>> > > As MetaObject accepts an ObjectWrapper as its object parameter...
>> > >
>> > > if (object instanceof ObjectWrapper) {
>> > > this.objectWrapper = (ObjectWrapper) object;
>> > > } else if (object instanceof Map) {
>> > > this.objectWrapper = new MapWrapper(this, (Map)object);
>> > > } else {
>> > > this.objectWrapper = new BeanWrapper(this, object);
>> > > }
>> > >
>> > > ...one solution would be to implement a custom ObjectFactory that
>> > > wraps the instances created by DefaultObjectFactory inside an
>> > > appropriate custom ObjectWrapper, say FieldObjectWrapper. But as
>> > > Reflector assumes the property-then-field precendence,
>> > > FieldObjectWrapper would have to be written from scratch, because
>> > > MetaObject, MetaClass and Reflector would render useless for my
>> > > purposes.
>> > >
>> > > What do you think about adding a global configuration option to set
>> > > the field/property resolution order? The change is trivial to
>> > > implement (just a few tweaks to Reflector, I think), and will be
>> > > backwards compatible if the default order remains property-then-field.
>> > >
>> > > This could be very valuable for developers that prefer to go the other
>> > > way around, and at a very low cost for ibatis itself. Also, having
>> > > properties as a last resort is handy even if you prefer field access
>> > > by default.
>> > >
>> > > Best regards
>> > > --
>> > > Carlos
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
>> > > For additional commands, e-mail: user-java-h...@ibatis.apache.org
>> > >
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
>> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>>
>>
>
