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.be...@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
>> > <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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
