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
>
>

Reply via email to