ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Ellis <ellis....@gmail.com>
Subject Re: Scala object support in iBATIS 3
Date Thu, 07 Jan 2010 21:44:58 GMT
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 <clinton.begin@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 <chris@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 <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
>> >>>
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message