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