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 <clinton.be...@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....@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-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
>
