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 Fri, 01 Jan 2010 03:05:48 GMT
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

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

View raw message