ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Reeves <ch...@ev-soft.net>
Subject Re: Scala object support in iBATIS 3
Date Sun, 03 Jan 2010 02:42:11 GMT
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 <chris@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 <clinton.begin@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 <ellis.m.a@gmail.com> wrote:
>>>
>>> 2009/12/31 Chris Reeves <chris@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
>>>
>>
>>
>

Mime
View raw message