You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Chris Reeves <ch...@ev-soft.net> on 2009/12/31 06:41:38 UTC
Scala object support in iBATIS 3
Hello,
I would like to add support for scala objects to iBATIS 3 for a
project I'm working on, and I have a few questions before I dive in
too deep.
>From what I can tell, this basically entails adding a new wrapper in
org.apache.ibatis.reflection.wrapper that can handle scala's slightly
different property naming conventions. Then, the forObject method in
MetaObject would need to use the new wrapper for the appropriate
objects. Is that more or less all that is necessary, or have I missed
something? I will be playing with this tomorrow, but I though I'd ask
the community as well.
Assuming I'm on the right track, I wonder if it would make sense to
have a factory for wrappers that could be modified as part of the
configuration. This would allow the scala support to be added to the
project in a contrib module so the main project would have no
dependencies on the scala libraries, as I will probably use the
ScalaObject marker interface to create the appropriate wrapper. Of
course, if no one else is interested in native scala object support,
this is moot.
However, other getter/setter naming strategies that don't conform to
the javabeans spec could also be plugged in if there was a
configurable wrapper factory, which probably isn't very useful to most
java developers, but may be useful for other jvm languages or some
seriously strange legacy cruft.
Thanks, Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Scala object support in iBATIS 3
Posted by Clinton Begin <cl...@gmail.com>.
Hey guys, I've implemented this. It's no longer static, so you can have
multiple configurations in the same VM with different
ObjectWrapperFactories.
It will be in Beta 8.
Clinton
On Thu, Jan 7, 2010 at 3:42 PM, Chris Reeves <ch...@ev-soft.net> wrote:
> I did: http://issues.apache.org/jira/browse/IBATIS-725
>
> Yeah, I noticed the indentation issues later and there are a few bugs
> in the code for scala objects. The patch for the core seems to work
> well, excepting configuration, which isn't in the dtd. This was my
> first time using textmate and I thought I had it set up to do the
> right thing with indentation. I will update the ticket with a properly
> formatted patch and my current version of the scala object wrapper
> code, which works but is probably not the sort of stuff you want in a
> library api.
>
> For whatever it's worth, I have used the code to implement wrappers
> for javabeans, scala objects, objects with different but uniform
> property-to-field naming, and a playing-around property framework
> similar to bean-properties or liftweb's Mapper/Record.
>
> I probably won't get to use this in my current project, since there
> isn't support for a few things that I need, like refreshing an object
> from the database and updating properties on insert and update for an
> optimistic locking type system, but I would be glad to clean the code
> up if it would be useful for anyone else.
>
> Thanks, Chris
>
>
>
> On Thu, Jan 7, 2010 at 4:44 PM, Martin Ellis <el...@gmail.com> wrote:
> > Hi, Chris,
> >
> > Did you create a JIRA ticket for this?
> >
> > I was hoping to get a proper chance to look over this, but haven't
> > managed as yet.
> >
> > One thing I did notice on a superficial glance is the indentation in
> > the files isn't consistent (I said it was superficial!). I guess you
> > have different tab width settings, but might be better to convert the
> > tabs to spaces before it goes into JIRA, assuming it's not already
> > there.
> >
> > Cheers
> > Martin
> >
> >
> > 2010/1/3 Clinton Begin <cl...@gmail.com>:
> >> Cool. Thanks Chris. You might do well to create a Jira ticket (New
> >> Feature) and attach the zip file there.
> >>
> >> Clinton
> >>
> >> On Sat, Jan 2, 2010 at 7:42 PM, Chris Reeves <ch...@ev-soft.net> wrote:
> >>>
> >>> For those who may be interested, here is my implementation of a scala
> >>> object wrapper. It includes an abstract base class that could be used
> >>> to implement a plain javabean wrapper, a javabean wrapper that uses
> >>> method names that don't exactly match the property name (i.e.
> >>> first_name -> getFirstName/setFirstName), etc.
> >>>
> >>> If for some reason you don't want to use reflection, you could also
> >>> use this support to generate static wrappers for your domain objects.
> >>> I'm not sure where else reflection is used in iBATIS though, so that
> >>> may not be useful.
> >>>
> >>> Thanks, Chris
> >>>
> >>>
> >>>
> >>> On Thu, Dec 31, 2009 at 10:05 PM, Chris Reeves <ch...@ev-soft.net>
> wrote:
> >>> > Thanks Clinton; for an excellent mapper that's well designed and for
> >>> > the pointers.
> >>> >
> >>> > Here is what I came up with for an object wrapper factory. I don't
> >>> > really like keeping it in static field on MetaObject, but I couldn't
> >>> > come up with anything better. I'm not entirely certain the xml
> >>> > configuration part is done correctly, but it adds
> >>> > <ObjectWrapperFactory type="com.something.MyFactory" /> in the same
> >>> > way as ObjectFactory.
> >>> >
> >>> > I was hoping to be able to subclass BeanWrapper to accomplish my goal
> >>> > of supporting scala objects, but it looks like it delegates to much
> to
> >>> > Reflector and MetaClass. I will post my code for a scala object
> >>> > wrapper and more generic base class when I complete it, if anyone is
> >>> > interested.
> >>> >
> >>> > Thanks, Chris
> >>> >
> >>> >
> >>> >
> >>> > On Thu, Dec 31, 2009 at 11:00 AM, Clinton Begin
> >>> > <cl...@gmail.com> wrote:
> >>> >> For both cases, I believe all necessary changes would be in the
> >>> >> wrappers.
> >>> >> However, there are places where Map is treated like a special case.
> >>> >> But as
> >>> >> long as you stick to making a peer to the bean wrapper, then you
> should
> >>> >> be
> >>> >> fine.
> >>> >>
> >>> >> While there's no factory class, the MetaObject framework uses a
> factory
> >>> >> method w/ delegates rather than a constructor, and is aware of all
> >>> >> known
> >>> >> implementations.
> >>> >>
> >>> >> private MetaObject(Object object, ObjectFactory objectFactory) {
> >>> >> this.originalObject = object;
> >>> >> this.objectFactory = objectFactory;
> >>> >> 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);
> >>> >> }
> >>> >> }
> >>> >>
> >>> >> public static MetaObject forObject(Object object, ObjectFactory
> >>> >> objectFactory) {
> >>> >> if (object == null) {
> >>> >> return NULL_META_OBJECT;
> >>> >> } else {
> >>> >> return new MetaObject(object, objectFactory);
> >>> >> }
> >>> >> }
> >>> >>
> >>> >>
> >>> >> So perhaps one implementation could be a 3rd party wrapper factory
> that
> >>> >> can
> >>> >> provide the new delegate. It should be easy for you to code this,
> but
> >>> >> the
> >>> >> pain in the butt always comes down to where to configure such a
> thing.
> >>> >> I
> >>> >> suppose just a new root config level element like <MetaClassWrapper
> >>> >> type="com.something.ScalaObjectWrappperFactory"/> The factory could
> >>> >> have a
> >>> >> method like: isWrapperFor(Class type).
> >>> >>
> >>> >> Sounds perfectly possible. Then we could add external support for
> >>> >> things
> >>> >> like dynabeans etc.
> >>> >>
> >>> >> Also, for Martin, I _think_ this might be all that is needed to
> create
> >>> >> support for custom column translations like: first_name =>
> firstName
> >>> >> etc.
> >>> >>
> >>> >> Clinton
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Thu, Dec 31, 2009 at 5:11 AM, Martin Ellis <el...@gmail.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> 2009/12/31 Chris Reeves <ch...@ev-soft.net>:
> >>> >>> > I would like to add support for scala objects to iBATIS 3 for a
> >>> >>> > project I'm working on, and I have a few questions before I dive
> in
> >>> >>> > too deep.
> >>> >>>
> >>> >>> Sounds interesting.
> >>> >>> I assume you're referring to the need to call foo_= instead of
> setFoo.
> >>> >>>
> >>> >>> > This would allow the scala support to be added to the
> >>> >>> > project in a contrib module so the main project would have no
> >>> >>> > dependencies on the scala libraries, as I will probably use the
> >>> >>> > ScalaObject marker interface to create the appropriate wrapper.
> Of
> >>> >>> > course, if no one else is interested in native scala object
> support,
> >>> >>> > this is moot.
> >>> >>>
> >>> >>> Not sure I follow. Is there any benefit in casting to ScalaObject?
> I
> >>> >>> wonder whether it's possible to reference the ScalaObject interface
> by
> >>> >>> name only (hence, no need to link to it).
> >>> >>>
> >>> >>> Another option (if you do want to link to the scala libraries)
> might
> >>> >>> be to make it an optional dependency. Currently, iBATIS has build
> >>> >>> dependencies on all sorts of logging frameworks, but they're all
> >>> >>> optional at runtime. Could do a similar thing with the scala libs
> (I
> >>> >>> assume you're thinking about writing the integration in Java).
> >>> >>>
> >>> >>> > However, other getter/setter naming strategies that don't conform
> to
> >>> >>> > the javabeans spec could also be plugged in if there was a
> >>> >>> > configurable wrapper factory, which probably isn't very useful to
> >>> >>> > most
> >>> >>> > java developers, but may be useful for other jvm languages or
> some
> >>> >>> > seriously strange legacy cruft.
> >>> >>>
> >>> >>> On the other hand, even for code with conventional getter/setter
> >>> >>> naming, it might be useful for handling different column naming
> >>> >>> conventions.
> >>> >>>
> >>> >>> In the iBATIS app I'm working on, all the database columns have
> >>> >>> underscore_names, so I've ended up using column aliasing (SELECT
> >>> >>> foo_bar fooBar, ...) for each column.
> >>> >>>
> >>> >>> I never figured out whether there was a better way to do this, but
> at
> >>> >>> the time I was looking for a way to implement exactly the
> 'pluggable'
> >>> >>> naming strategies you describe.
> >>> >>>
> >>> >>>
> >>> >>> Martin
> >>> >>>
> >>> >>>
> ---------------------------------------------------------------------
> >>> >>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> >>> >>> For additional commands, e-mail: user-java-help@ibatis.apache.org
> >>> >>>
> >>> >>
> >>> >>
> >>> >
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> >>> For additional commands, e-mail: user-java-help@ibatis.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> > For additional commands, e-mail: user-java-help@ibatis.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: Scala object support in iBATIS 3
Posted by Chris Reeves <ch...@ev-soft.net>.
I did: http://issues.apache.org/jira/browse/IBATIS-725
Yeah, I noticed the indentation issues later and there are a few bugs
in the code for scala objects. The patch for the core seems to work
well, excepting configuration, which isn't in the dtd. This was my
first time using textmate and I thought I had it set up to do the
right thing with indentation. I will update the ticket with a properly
formatted patch and my current version of the scala object wrapper
code, which works but is probably not the sort of stuff you want in a
library api.
For whatever it's worth, I have used the code to implement wrappers
for javabeans, scala objects, objects with different but uniform
property-to-field naming, and a playing-around property framework
similar to bean-properties or liftweb's Mapper/Record.
I probably won't get to use this in my current project, since there
isn't support for a few things that I need, like refreshing an object
from the database and updating properties on insert and update for an
optimistic locking type system, but I would be glad to clean the code
up if it would be useful for anyone else.
Thanks, Chris
On Thu, Jan 7, 2010 at 4:44 PM, Martin Ellis <el...@gmail.com> wrote:
> Hi, Chris,
>
> Did you create a JIRA ticket for this?
>
> I was hoping to get a proper chance to look over this, but haven't
> managed as yet.
>
> One thing I did notice on a superficial glance is the indentation in
> the files isn't consistent (I said it was superficial!). I guess you
> have different tab width settings, but might be better to convert the
> tabs to spaces before it goes into JIRA, assuming it's not already
> there.
>
> Cheers
> Martin
>
>
> 2010/1/3 Clinton Begin <cl...@gmail.com>:
>> Cool. Thanks Chris. You might do well to create a Jira ticket (New
>> Feature) and attach the zip file there.
>>
>> Clinton
>>
>> On Sat, Jan 2, 2010 at 7:42 PM, Chris Reeves <ch...@ev-soft.net> wrote:
>>>
>>> For those who may be interested, here is my implementation of a scala
>>> object wrapper. It includes an abstract base class that could be used
>>> to implement a plain javabean wrapper, a javabean wrapper that uses
>>> method names that don't exactly match the property name (i.e.
>>> first_name -> getFirstName/setFirstName), etc.
>>>
>>> If for some reason you don't want to use reflection, you could also
>>> use this support to generate static wrappers for your domain objects.
>>> I'm not sure where else reflection is used in iBATIS though, so that
>>> may not be useful.
>>>
>>> Thanks, Chris
>>>
>>>
>>>
>>> On Thu, Dec 31, 2009 at 10:05 PM, Chris Reeves <ch...@ev-soft.net> wrote:
>>> > Thanks Clinton; for an excellent mapper that's well designed and for
>>> > the pointers.
>>> >
>>> > Here is what I came up with for an object wrapper factory. I don't
>>> > really like keeping it in static field on MetaObject, but I couldn't
>>> > come up with anything better. I'm not entirely certain the xml
>>> > configuration part is done correctly, but it adds
>>> > <ObjectWrapperFactory type="com.something.MyFactory" /> in the same
>>> > way as ObjectFactory.
>>> >
>>> > I was hoping to be able to subclass BeanWrapper to accomplish my goal
>>> > of supporting scala objects, but it looks like it delegates to much to
>>> > Reflector and MetaClass. I will post my code for a scala object
>>> > wrapper and more generic base class when I complete it, if anyone is
>>> > interested.
>>> >
>>> > Thanks, Chris
>>> >
>>> >
>>> >
>>> > On Thu, Dec 31, 2009 at 11:00 AM, Clinton Begin
>>> > <cl...@gmail.com> wrote:
>>> >> For both cases, I believe all necessary changes would be in the
>>> >> wrappers.
>>> >> However, there are places where Map is treated like a special case.
>>> >> But as
>>> >> long as you stick to making a peer to the bean wrapper, then you should
>>> >> be
>>> >> fine.
>>> >>
>>> >> While there's no factory class, the MetaObject framework uses a factory
>>> >> method w/ delegates rather than a constructor, and is aware of all
>>> >> known
>>> >> implementations.
>>> >>
>>> >> private MetaObject(Object object, ObjectFactory objectFactory) {
>>> >> this.originalObject = object;
>>> >> this.objectFactory = objectFactory;
>>> >> 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);
>>> >> }
>>> >> }
>>> >>
>>> >> public static MetaObject forObject(Object object, ObjectFactory
>>> >> objectFactory) {
>>> >> if (object == null) {
>>> >> return NULL_META_OBJECT;
>>> >> } else {
>>> >> return new MetaObject(object, objectFactory);
>>> >> }
>>> >> }
>>> >>
>>> >>
>>> >> So perhaps one implementation could be a 3rd party wrapper factory that
>>> >> can
>>> >> provide the new delegate. It should be easy for you to code this, but
>>> >> the
>>> >> pain in the butt always comes down to where to configure such a thing.
>>> >> I
>>> >> suppose just a new root config level element like <MetaClassWrapper
>>> >> type="com.something.ScalaObjectWrappperFactory"/> The factory could
>>> >> have a
>>> >> method like: isWrapperFor(Class type).
>>> >>
>>> >> Sounds perfectly possible. Then we could add external support for
>>> >> things
>>> >> like dynabeans etc.
>>> >>
>>> >> Also, for Martin, I _think_ this might be all that is needed to create
>>> >> support for custom column translations like: first_name => firstName
>>> >> etc.
>>> >>
>>> >> Clinton
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Dec 31, 2009 at 5:11 AM, Martin Ellis <el...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> 2009/12/31 Chris Reeves <ch...@ev-soft.net>:
>>> >>> > I would like to add support for scala objects to iBATIS 3 for a
>>> >>> > project I'm working on, and I have a few questions before I dive in
>>> >>> > too deep.
>>> >>>
>>> >>> Sounds interesting.
>>> >>> I assume you're referring to the need to call foo_= instead of setFoo.
>>> >>>
>>> >>> > This would allow the scala support to be added to the
>>> >>> > project in a contrib module so the main project would have no
>>> >>> > dependencies on the scala libraries, as I will probably use the
>>> >>> > ScalaObject marker interface to create the appropriate wrapper. Of
>>> >>> > course, if no one else is interested in native scala object support,
>>> >>> > this is moot.
>>> >>>
>>> >>> Not sure I follow. Is there any benefit in casting to ScalaObject? I
>>> >>> wonder whether it's possible to reference the ScalaObject interface by
>>> >>> name only (hence, no need to link to it).
>>> >>>
>>> >>> Another option (if you do want to link to the scala libraries) might
>>> >>> be to make it an optional dependency. Currently, iBATIS has build
>>> >>> dependencies on all sorts of logging frameworks, but they're all
>>> >>> optional at runtime. Could do a similar thing with the scala libs (I
>>> >>> assume you're thinking about writing the integration in Java).
>>> >>>
>>> >>> > However, other getter/setter naming strategies that don't conform to
>>> >>> > the javabeans spec could also be plugged in if there was a
>>> >>> > configurable wrapper factory, which probably isn't very useful to
>>> >>> > most
>>> >>> > java developers, but may be useful for other jvm languages or some
>>> >>> > seriously strange legacy cruft.
>>> >>>
>>> >>> On the other hand, even for code with conventional getter/setter
>>> >>> naming, it might be useful for handling different column naming
>>> >>> conventions.
>>> >>>
>>> >>> In the iBATIS app I'm working on, all the database columns have
>>> >>> underscore_names, so I've ended up using column aliasing (SELECT
>>> >>> foo_bar fooBar, ...) for each column.
>>> >>>
>>> >>> I never figured out whether there was a better way to do this, but at
>>> >>> the time I was looking for a way to implement exactly the 'pluggable'
>>> >>> naming strategies you describe.
>>> >>>
>>> >>>
>>> >>> Martin
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>> >>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Scala object support in iBATIS 3
Posted by Martin Ellis <el...@gmail.com>.
Hi, Chris,
Did you create a JIRA ticket for this?
I was hoping to get a proper chance to look over this, but haven't
managed as yet.
One thing I did notice on a superficial glance is the indentation in
the files isn't consistent (I said it was superficial!). I guess you
have different tab width settings, but might be better to convert the
tabs to spaces before it goes into JIRA, assuming it's not already
there.
Cheers
Martin
2010/1/3 Clinton Begin <cl...@gmail.com>:
> Cool. Thanks Chris. You might do well to create a Jira ticket (New
> Feature) and attach the zip file there.
>
> Clinton
>
> On Sat, Jan 2, 2010 at 7:42 PM, Chris Reeves <ch...@ev-soft.net> wrote:
>>
>> For those who may be interested, here is my implementation of a scala
>> object wrapper. It includes an abstract base class that could be used
>> to implement a plain javabean wrapper, a javabean wrapper that uses
>> method names that don't exactly match the property name (i.e.
>> first_name -> getFirstName/setFirstName), etc.
>>
>> If for some reason you don't want to use reflection, you could also
>> use this support to generate static wrappers for your domain objects.
>> I'm not sure where else reflection is used in iBATIS though, so that
>> may not be useful.
>>
>> Thanks, Chris
>>
>>
>>
>> On Thu, Dec 31, 2009 at 10:05 PM, Chris Reeves <ch...@ev-soft.net> wrote:
>> > Thanks Clinton; for an excellent mapper that's well designed and for
>> > the pointers.
>> >
>> > Here is what I came up with for an object wrapper factory. I don't
>> > really like keeping it in static field on MetaObject, but I couldn't
>> > come up with anything better. I'm not entirely certain the xml
>> > configuration part is done correctly, but it adds
>> > <ObjectWrapperFactory type="com.something.MyFactory" /> in the same
>> > way as ObjectFactory.
>> >
>> > I was hoping to be able to subclass BeanWrapper to accomplish my goal
>> > of supporting scala objects, but it looks like it delegates to much to
>> > Reflector and MetaClass. I will post my code for a scala object
>> > wrapper and more generic base class when I complete it, if anyone is
>> > interested.
>> >
>> > Thanks, Chris
>> >
>> >
>> >
>> > On Thu, Dec 31, 2009 at 11:00 AM, Clinton Begin
>> > <cl...@gmail.com> wrote:
>> >> For both cases, I believe all necessary changes would be in the
>> >> wrappers.
>> >> However, there are places where Map is treated like a special case.
>> >> But as
>> >> long as you stick to making a peer to the bean wrapper, then you should
>> >> be
>> >> fine.
>> >>
>> >> While there's no factory class, the MetaObject framework uses a factory
>> >> method w/ delegates rather than a constructor, and is aware of all
>> >> known
>> >> implementations.
>> >>
>> >> private MetaObject(Object object, ObjectFactory objectFactory) {
>> >> this.originalObject = object;
>> >> this.objectFactory = objectFactory;
>> >> 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);
>> >> }
>> >> }
>> >>
>> >> public static MetaObject forObject(Object object, ObjectFactory
>> >> objectFactory) {
>> >> if (object == null) {
>> >> return NULL_META_OBJECT;
>> >> } else {
>> >> return new MetaObject(object, objectFactory);
>> >> }
>> >> }
>> >>
>> >>
>> >> So perhaps one implementation could be a 3rd party wrapper factory that
>> >> can
>> >> provide the new delegate. It should be easy for you to code this, but
>> >> the
>> >> pain in the butt always comes down to where to configure such a thing.
>> >> I
>> >> suppose just a new root config level element like <MetaClassWrapper
>> >> type="com.something.ScalaObjectWrappperFactory"/> The factory could
>> >> have a
>> >> method like: isWrapperFor(Class type).
>> >>
>> >> Sounds perfectly possible. Then we could add external support for
>> >> things
>> >> like dynabeans etc.
>> >>
>> >> Also, for Martin, I _think_ this might be all that is needed to create
>> >> support for custom column translations like: first_name => firstName
>> >> etc.
>> >>
>> >> Clinton
>> >>
>> >>
>> >>
>> >> On Thu, Dec 31, 2009 at 5:11 AM, Martin Ellis <el...@gmail.com>
>> >> wrote:
>> >>>
>> >>> 2009/12/31 Chris Reeves <ch...@ev-soft.net>:
>> >>> > I would like to add support for scala objects to iBATIS 3 for a
>> >>> > project I'm working on, and I have a few questions before I dive in
>> >>> > too deep.
>> >>>
>> >>> Sounds interesting.
>> >>> I assume you're referring to the need to call foo_= instead of setFoo.
>> >>>
>> >>> > This would allow the scala support to be added to the
>> >>> > project in a contrib module so the main project would have no
>> >>> > dependencies on the scala libraries, as I will probably use the
>> >>> > ScalaObject marker interface to create the appropriate wrapper. Of
>> >>> > course, if no one else is interested in native scala object support,
>> >>> > this is moot.
>> >>>
>> >>> Not sure I follow. Is there any benefit in casting to ScalaObject? I
>> >>> wonder whether it's possible to reference the ScalaObject interface by
>> >>> name only (hence, no need to link to it).
>> >>>
>> >>> Another option (if you do want to link to the scala libraries) might
>> >>> be to make it an optional dependency. Currently, iBATIS has build
>> >>> dependencies on all sorts of logging frameworks, but they're all
>> >>> optional at runtime. Could do a similar thing with the scala libs (I
>> >>> assume you're thinking about writing the integration in Java).
>> >>>
>> >>> > However, other getter/setter naming strategies that don't conform to
>> >>> > the javabeans spec could also be plugged in if there was a
>> >>> > configurable wrapper factory, which probably isn't very useful to
>> >>> > most
>> >>> > java developers, but may be useful for other jvm languages or some
>> >>> > seriously strange legacy cruft.
>> >>>
>> >>> On the other hand, even for code with conventional getter/setter
>> >>> naming, it might be useful for handling different column naming
>> >>> conventions.
>> >>>
>> >>> In the iBATIS app I'm working on, all the database columns have
>> >>> underscore_names, so I've ended up using column aliasing (SELECT
>> >>> foo_bar fooBar, ...) for each column.
>> >>>
>> >>> I never figured out whether there was a better way to do this, but at
>> >>> the time I was looking for a way to implement exactly the 'pluggable'
>> >>> naming strategies you describe.
>> >>>
>> >>>
>> >>> Martin
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> >>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>> >>>
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Scala object support in iBATIS 3
Posted by Clinton Begin <cl...@gmail.com>.
Cool. Thanks Chris. You might do well to create a Jira ticket (New
Feature) and attach the zip file there.
Clinton
On Sat, Jan 2, 2010 at 7:42 PM, Chris Reeves <ch...@ev-soft.net> wrote:
> For those who may be interested, here is my implementation of a scala
> object wrapper. It includes an abstract base class that could be used
> to implement a plain javabean wrapper, a javabean wrapper that uses
> method names that don't exactly match the property name (i.e.
> first_name -> getFirstName/setFirstName), etc.
>
> If for some reason you don't want to use reflection, you could also
> use this support to generate static wrappers for your domain objects.
> I'm not sure where else reflection is used in iBATIS though, so that
> may not be useful.
>
> Thanks, Chris
>
>
>
> On Thu, Dec 31, 2009 at 10:05 PM, Chris Reeves <ch...@ev-soft.net> wrote:
> > Thanks Clinton; for an excellent mapper that's well designed and for
> > the pointers.
> >
> > Here is what I came up with for an object wrapper factory. I don't
> > really like keeping it in static field on MetaObject, but I couldn't
> > come up with anything better. I'm not entirely certain the xml
> > configuration part is done correctly, but it adds
> > <ObjectWrapperFactory type="com.something.MyFactory" /> in the same
> > way as ObjectFactory.
> >
> > I was hoping to be able to subclass BeanWrapper to accomplish my goal
> > of supporting scala objects, but it looks like it delegates to much to
> > Reflector and MetaClass. I will post my code for a scala object
> > wrapper and more generic base class when I complete it, if anyone is
> > interested.
> >
> > Thanks, Chris
> >
> >
> >
> > On Thu, Dec 31, 2009 at 11:00 AM, Clinton Begin <cl...@gmail.com>
> wrote:
> >> For both cases, I believe all necessary changes would be in the
> wrappers.
> >> However, there are places where Map is treated like a special case. But
> as
> >> long as you stick to making a peer to the bean wrapper, then you should
> be
> >> fine.
> >>
> >> While there's no factory class, the MetaObject framework uses a factory
> >> method w/ delegates rather than a constructor, and is aware of all known
> >> implementations.
> >>
> >> private MetaObject(Object object, ObjectFactory objectFactory) {
> >> this.originalObject = object;
> >> this.objectFactory = objectFactory;
> >> 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);
> >> }
> >> }
> >>
> >> public static MetaObject forObject(Object object, ObjectFactory
> >> objectFactory) {
> >> if (object == null) {
> >> return NULL_META_OBJECT;
> >> } else {
> >> return new MetaObject(object, objectFactory);
> >> }
> >> }
> >>
> >>
> >> So perhaps one implementation could be a 3rd party wrapper factory that
> can
> >> provide the new delegate. It should be easy for you to code this, but
> the
> >> pain in the butt always comes down to where to configure such a thing.
> I
> >> suppose just a new root config level element like <MetaClassWrapper
> >> type="com.something.ScalaObjectWrappperFactory"/> The factory could
> have a
> >> method like: isWrapperFor(Class type).
> >>
> >> Sounds perfectly possible. Then we could add external support for
> things
> >> like dynabeans etc.
> >>
> >> Also, for Martin, I _think_ this might be all that is needed to create
> >> support for custom column translations like: first_name => firstName
> etc.
> >>
> >> Clinton
> >>
> >>
> >>
> >> On Thu, Dec 31, 2009 at 5:11 AM, Martin Ellis <el...@gmail.com>
> wrote:
> >>>
> >>> 2009/12/31 Chris Reeves <ch...@ev-soft.net>:
> >>> > I would like to add support for scala objects to iBATIS 3 for a
> >>> > project I'm working on, and I have a few questions before I dive in
> >>> > too deep.
> >>>
> >>> Sounds interesting.
> >>> I assume you're referring to the need to call foo_= instead of setFoo.
> >>>
> >>> > This would allow the scala support to be added to the
> >>> > project in a contrib module so the main project would have no
> >>> > dependencies on the scala libraries, as I will probably use the
> >>> > ScalaObject marker interface to create the appropriate wrapper. Of
> >>> > course, if no one else is interested in native scala object support,
> >>> > this is moot.
> >>>
> >>> Not sure I follow. Is there any benefit in casting to ScalaObject? I
> >>> wonder whether it's possible to reference the ScalaObject interface by
> >>> name only (hence, no need to link to it).
> >>>
> >>> Another option (if you do want to link to the scala libraries) might
> >>> be to make it an optional dependency. Currently, iBATIS has build
> >>> dependencies on all sorts of logging frameworks, but they're all
> >>> optional at runtime. Could do a similar thing with the scala libs (I
> >>> assume you're thinking about writing the integration in Java).
> >>>
> >>> > However, other getter/setter naming strategies that don't conform to
> >>> > the javabeans spec could also be plugged in if there was a
> >>> > configurable wrapper factory, which probably isn't very useful to
> most
> >>> > java developers, but may be useful for other jvm languages or some
> >>> > seriously strange legacy cruft.
> >>>
> >>> On the other hand, even for code with conventional getter/setter
> >>> naming, it might be useful for handling different column naming
> >>> conventions.
> >>>
> >>> In the iBATIS app I'm working on, all the database columns have
> >>> underscore_names, so I've ended up using column aliasing (SELECT
> >>> foo_bar fooBar, ...) for each column.
> >>>
> >>> I never figured out whether there was a better way to do this, but at
> >>> the time I was looking for a way to implement exactly the 'pluggable'
> >>> naming strategies you describe.
> >>>
> >>>
> >>> Martin
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> >>> For additional commands, e-mail: user-java-help@ibatis.apache.org
> >>>
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
Re: Scala object support in iBATIS 3
Posted by Chris Reeves <ch...@ev-soft.net>.
For those who may be interested, here is my implementation of a scala
object wrapper. It includes an abstract base class that could be used
to implement a plain javabean wrapper, a javabean wrapper that uses
method names that don't exactly match the property name (i.e.
first_name -> getFirstName/setFirstName), etc.
If for some reason you don't want to use reflection, you could also
use this support to generate static wrappers for your domain objects.
I'm not sure where else reflection is used in iBATIS though, so that
may not be useful.
Thanks, Chris
On Thu, Dec 31, 2009 at 10:05 PM, Chris Reeves <ch...@ev-soft.net> wrote:
> Thanks Clinton; for an excellent mapper that's well designed and for
> the pointers.
>
> Here is what I came up with for an object wrapper factory. I don't
> really like keeping it in static field on MetaObject, but I couldn't
> come up with anything better. I'm not entirely certain the xml
> configuration part is done correctly, but it adds
> <ObjectWrapperFactory type="com.something.MyFactory" /> in the same
> way as ObjectFactory.
>
> I was hoping to be able to subclass BeanWrapper to accomplish my goal
> of supporting scala objects, but it looks like it delegates to much to
> Reflector and MetaClass. I will post my code for a scala object
> wrapper and more generic base class when I complete it, if anyone is
> interested.
>
> Thanks, Chris
>
>
>
> On Thu, Dec 31, 2009 at 11:00 AM, Clinton Begin <cl...@gmail.com> wrote:
>> For both cases, I believe all necessary changes would be in the wrappers.
>> However, there are places where Map is treated like a special case.� But as
>> long as you stick to making a peer to the bean wrapper, then you should be
>> fine.
>>
>> While there's no factory class, the MetaObject framework uses a factory
>> method w/ delegates rather than a constructor, and is aware of all known
>> implementations.
>>
>> � private MetaObject(Object object, ObjectFactory objectFactory) {
>> ��� this.originalObject = object;
>> ��� this.objectFactory = objectFactory;
>> ��� 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);
>> ��� }
>> � }
>>
>> � public static MetaObject forObject(Object object, ObjectFactory
>> objectFactory) {
>> ��� if (object == null) {
>> ����� return NULL_META_OBJECT;
>> ��� } else {
>> ����� return new MetaObject(object, objectFactory);
>> ��� }
>> � }
>>
>>
>> So perhaps one implementation could be a 3rd party wrapper factory that can
>> provide the new delegate.� It should be easy for you to code this, but the
>> pain in the butt always comes down to where to configure such a thing.� I
>> suppose just a new root config level element like <MetaClassWrapper
>> type="com.something.ScalaObjectWrappperFactory"/>� The factory could have a
>> method like:�� isWrapperFor(Class type).
>>
>> Sounds perfectly possible.� Then we could add external support for things
>> like dynabeans etc.
>>
>> Also, for Martin, I _think_ this might be all that is needed to create
>> support for custom column translations like:� first_name => firstName etc.
>>
>> Clinton
>>
>>
>>
>> On Thu, Dec 31, 2009 at 5:11 AM, Martin Ellis <el...@gmail.com> wrote:
>>>
>>> 2009/12/31 Chris Reeves <ch...@ev-soft.net>:
>>> > I would like to add support for scala objects to iBATIS 3 for a
>>> > project I'm working on, and I have a few questions before I dive in
>>> > too deep.
>>>
>>> Sounds interesting.
>>> I assume you're referring to the need to call foo_= instead of setFoo.
>>>
>>> > This would allow the scala support to be added to the
>>> > project in a contrib module so the main project would have no
>>> > dependencies on the scala libraries, as I will probably use the
>>> > ScalaObject marker interface to create the appropriate wrapper. Of
>>> > course, if no one else is interested in native scala object support,
>>> > this is moot.
>>>
>>> Not sure I follow. �Is there any benefit in casting to ScalaObject? I
>>> wonder whether it's possible to reference the ScalaObject interface by
>>> name only (hence, no need to link to it).
>>>
>>> Another option (if you do want to link to the scala libraries) might
>>> be to make it an optional dependency. �Currently, iBATIS has build
>>> dependencies on all sorts of logging frameworks, but they're all
>>> optional at runtime. �Could do a similar thing with the scala libs (I
>>> assume you're thinking about writing the integration in Java).
>>>
>>> > However, other getter/setter naming strategies that don't conform to
>>> > the javabeans spec could also be plugged in if there was a
>>> > configurable wrapper factory, which probably isn't very useful to most
>>> > java developers, but may be useful for other jvm languages or some
>>> > seriously strange legacy cruft.
>>>
>>> On the other hand, even for code with conventional getter/setter
>>> naming, it might be useful for handling different column naming
>>> conventions.
>>>
>>> In the iBATIS app I'm working on, all the database columns have
>>> underscore_names, so I've ended up using column aliasing (SELECT
>>> foo_bar fooBar, ...) for each column.
>>>
>>> I never figured out whether there was a better way to do this, but at
>>> the time I was looking for a way to implement exactly the 'pluggable'
>>> naming strategies you describe.
>>>
>>>
>>> Martin
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>
>>
>>
>
Re: Scala object support in iBATIS 3
Posted by Chris Reeves <ch...@ev-soft.net>.
Thanks Clinton; for an excellent mapper that's well designed and for
the pointers.
Here is what I came up with for an object wrapper factory. I don't
really like keeping it in static field on MetaObject, but I couldn't
come up with anything better. I'm not entirely certain the xml
configuration part is done correctly, but it adds
<ObjectWrapperFactory type="com.something.MyFactory" /> in the same
way as ObjectFactory.
I was hoping to be able to subclass BeanWrapper to accomplish my goal
of supporting scala objects, but it looks like it delegates to much to
Reflector and MetaClass. I will post my code for a scala object
wrapper and more generic base class when I complete it, if anyone is
interested.
Thanks, Chris
On Thu, Dec 31, 2009 at 11:00 AM, Clinton Begin <cl...@gmail.com> wrote:
> For both cases, I believe all necessary changes would be in the wrappers.
> However, there are places where Map is treated like a special case.� But as
> long as you stick to making a peer to the bean wrapper, then you should be
> fine.
>
> While there's no factory class, the MetaObject framework uses a factory
> method w/ delegates rather than a constructor, and is aware of all known
> implementations.
>
> � private MetaObject(Object object, ObjectFactory objectFactory) {
> ��� this.originalObject = object;
> ��� this.objectFactory = objectFactory;
> ��� 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);
> ��� }
> � }
>
> � public static MetaObject forObject(Object object, ObjectFactory
> objectFactory) {
> ��� if (object == null) {
> ����� return NULL_META_OBJECT;
> ��� } else {
> ����� return new MetaObject(object, objectFactory);
> ��� }
> � }
>
>
> So perhaps one implementation could be a 3rd party wrapper factory that can
> provide the new delegate.� It should be easy for you to code this, but the
> pain in the butt always comes down to where to configure such a thing.� I
> suppose just a new root config level element like <MetaClassWrapper
> type="com.something.ScalaObjectWrappperFactory"/>� The factory could have a
> method like:�� isWrapperFor(Class type).
>
> Sounds perfectly possible.� Then we could add external support for things
> like dynabeans etc.
>
> Also, for Martin, I _think_ this might be all that is needed to create
> support for custom column translations like:� first_name => firstName etc.
>
> Clinton
>
>
>
> On Thu, Dec 31, 2009 at 5:11 AM, Martin Ellis <el...@gmail.com> wrote:
>>
>> 2009/12/31 Chris Reeves <ch...@ev-soft.net>:
>> > I would like to add support for scala objects to iBATIS 3 for a
>> > project I'm working on, and I have a few questions before I dive in
>> > too deep.
>>
>> Sounds interesting.
>> I assume you're referring to the need to call foo_= instead of setFoo.
>>
>> > This would allow the scala support to be added to the
>> > project in a contrib module so the main project would have no
>> > dependencies on the scala libraries, as I will probably use the
>> > ScalaObject marker interface to create the appropriate wrapper. Of
>> > course, if no one else is interested in native scala object support,
>> > this is moot.
>>
>> Not sure I follow. �Is there any benefit in casting to ScalaObject? I
>> wonder whether it's possible to reference the ScalaObject interface by
>> name only (hence, no need to link to it).
>>
>> Another option (if you do want to link to the scala libraries) might
>> be to make it an optional dependency. �Currently, iBATIS has build
>> dependencies on all sorts of logging frameworks, but they're all
>> optional at runtime. �Could do a similar thing with the scala libs (I
>> assume you're thinking about writing the integration in Java).
>>
>> > However, other getter/setter naming strategies that don't conform to
>> > the javabeans spec could also be plugged in if there was a
>> > configurable wrapper factory, which probably isn't very useful to most
>> > java developers, but may be useful for other jvm languages or some
>> > seriously strange legacy cruft.
>>
>> On the other hand, even for code with conventional getter/setter
>> naming, it might be useful for handling different column naming
>> conventions.
>>
>> In the iBATIS app I'm working on, all the database columns have
>> underscore_names, so I've ended up using column aliasing (SELECT
>> foo_bar fooBar, ...) for each column.
>>
>> I never figured out whether there was a better way to do this, but at
>> the time I was looking for a way to implement exactly the 'pluggable'
>> naming strategies you describe.
>>
>>
>> Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>
>
Re: Scala object support in iBATIS 3
Posted by Clinton Begin <cl...@gmail.com>.
For both cases, I believe all necessary changes would be in the wrappers.
However, there are places where Map is treated like a special case. But as
long as you stick to making a peer to the bean wrapper, then you should be
fine.
While there's no factory class, the MetaObject framework uses a factory
method w/ delegates rather than a constructor, and is aware of all known
implementations.
private MetaObject(Object object, ObjectFactory objectFactory) {
this.originalObject = object;
this.objectFactory = objectFactory;
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);
}
}
public static MetaObject forObject(Object object, ObjectFactory
objectFactory) {
if (object == null) {
return NULL_META_OBJECT;
} else {
return new MetaObject(object, objectFactory);
}
}
So perhaps one implementation could be a 3rd party wrapper factory that can
provide the new delegate. It should be easy for you to code this, but the
pain in the butt always comes down to where to configure such a thing. I
suppose just a new root config level element like <MetaClassWrapper
type="com.something.ScalaObjectWrappperFactory"/> The factory could have a
method like: isWrapperFor(Class type).
Sounds perfectly possible. Then we could add external support for things
like dynabeans etc.
Also, for Martin, I _think_ this might be all that is needed to create
support for custom column translations like: first_name => firstName etc.
Clinton
On Thu, Dec 31, 2009 at 5:11 AM, Martin Ellis <el...@gmail.com> wrote:
> 2009/12/31 Chris Reeves <ch...@ev-soft.net>:
> > I would like to add support for scala objects to iBATIS 3 for a
> > project I'm working on, and I have a few questions before I dive in
> > too deep.
>
> Sounds interesting.
> I assume you're referring to the need to call foo_= instead of setFoo.
>
> > This would allow the scala support to be added to the
> > project in a contrib module so the main project would have no
> > dependencies on the scala libraries, as I will probably use the
> > ScalaObject marker interface to create the appropriate wrapper. Of
> > course, if no one else is interested in native scala object support,
> > this is moot.
>
> Not sure I follow. Is there any benefit in casting to ScalaObject? I
> wonder whether it's possible to reference the ScalaObject interface by
> name only (hence, no need to link to it).
>
> Another option (if you do want to link to the scala libraries) might
> be to make it an optional dependency. Currently, iBATIS has build
> dependencies on all sorts of logging frameworks, but they're all
> optional at runtime. Could do a similar thing with the scala libs (I
> assume you're thinking about writing the integration in Java).
>
> > However, other getter/setter naming strategies that don't conform to
> > the javabeans spec could also be plugged in if there was a
> > configurable wrapper factory, which probably isn't very useful to most
> > java developers, but may be useful for other jvm languages or some
> > seriously strange legacy cruft.
>
> On the other hand, even for code with conventional getter/setter
> naming, it might be useful for handling different column naming
> conventions.
>
> In the iBATIS app I'm working on, all the database columns have
> underscore_names, so I've ended up using column aliasing (SELECT
> foo_bar fooBar, ...) for each column.
>
> I never figured out whether there was a better way to do this, but at
> the time I was looking for a way to implement exactly the 'pluggable'
> naming strategies you describe.
>
>
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: Scala object support in iBATIS 3
Posted by Chris Reeves <ch...@ev-soft.net>.
> Sounds interesting.
> I assume you're referring to the need to call foo_= instead of setFoo.
Yes, though I believe it ends up being foo_$eq.
> Not sure I follow. Is there any benefit in casting to ScalaObject? I
> wonder whether it's possible to reference the ScalaObject interface by
> name only (hence, no need to link to it).
I was going to go the easy route and just add a check for object
instanceof ScalaObject, but I suppose it could be done with just
strings.
> Another option (if you do want to link to the scala libraries) might
> be to make it an optional dependency. Currently, iBATIS has build
> dependencies on all sorts of logging frameworks, but they're all
> optional at runtime. Could do a similar thing with the scala libs (I
> assume you're thinking about writing the integration in Java).
Yes, I don't see any advantage in bringing in a 3mb dependency for
something like this, so I'd do the implementation in Java. Speaking of
build dependencies, is there a document somewhere in the ether that
describes the build process for iBATIS 3? Everything I've found only
references mapper2.
> In the iBATIS app I'm working on, all the database columns have
> underscore_names, so I've ended up using column aliasing (SELECT
> foo_bar fooBar, ...) for each column.
>
> I never figured out whether there was a better way to do this, but at
> the time I was looking for a way to implement exactly the 'pluggable'
> naming strategies you describe.
I didn't consider it from that side, but I suppose that would be
useful. I'll write up a patch and see what everyone thinks. I'm glad
there is some interest in this.
Thanks, Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Scala object support in iBATIS 3
Posted by Martin Ellis <el...@gmail.com>.
2009/12/31 Chris Reeves <ch...@ev-soft.net>:
> I would like to add support for scala objects to iBATIS 3 for a
> project I'm working on, and I have a few questions before I dive in
> too deep.
Sounds interesting.
I assume you're referring to the need to call foo_= instead of setFoo.
> This would allow the scala support to be added to the
> project in a contrib module so the main project would have no
> dependencies on the scala libraries, as I will probably use the
> ScalaObject marker interface to create the appropriate wrapper. Of
> course, if no one else is interested in native scala object support,
> this is moot.
Not sure I follow. Is there any benefit in casting to ScalaObject? I
wonder whether it's possible to reference the ScalaObject interface by
name only (hence, no need to link to it).
Another option (if you do want to link to the scala libraries) might
be to make it an optional dependency. Currently, iBATIS has build
dependencies on all sorts of logging frameworks, but they're all
optional at runtime. Could do a similar thing with the scala libs (I
assume you're thinking about writing the integration in Java).
> However, other getter/setter naming strategies that don't conform to
> the javabeans spec could also be plugged in if there was a
> configurable wrapper factory, which probably isn't very useful to most
> java developers, but may be useful for other jvm languages or some
> seriously strange legacy cruft.
On the other hand, even for code with conventional getter/setter
naming, it might be useful for handling different column naming
conventions.
In the iBATIS app I'm working on, all the database columns have
underscore_names, so I've ended up using column aliasing (SELECT
foo_bar fooBar, ...) for each column.
I never figured out whether there was a better way to do this, but at
the time I was looking for a way to implement exactly the 'pluggable'
naming strategies you describe.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org