[prev in list] [next in list] [prev in thread] [next in thread] 

List:       castor-dev
Subject:    Re: [castor-dev] Source Generator & mapping-binding
From:       "Arnaud Blandin" <blandin () intalio ! com>
Date:       2002-12-30 16:35:46
[Download RAW message or body]

Hi Rhett,

It seems that I introduced some confusion in your mind with my answers;
I will try to clarify my thoughts with this post.

When defining a custom binding, you can change the name of the generated
class by using the <java-class/> element but this will have NO effect on
the member generated to refer to the generated class.
To change the name of the member, you have to use the <member/> element
and I thought you were using it. I just fixed the CVS so that now the
methods generated in a collection will reflect the name specified in the
<member/> element.
Concerning your ideas on the enumeration handling, thanks for sharing
that with me; I will make sure I include requests 1) and 2) when
implementing it.
Thanks for all the feedback given and for your willingness to enhance
Castor,

Arnaud

> -----Original Message-----
> From: Rhett Sutphin [mailto:rhett-sutphin@uiowa.edu]
> Sent: Thursday, December 26, 2002 6:00 PM
> To: castor-dev@exolab.org
> Subject: Re: [castor-dev] Source Generator & mapping-binding
> 
> Hi Arnaud,
> 
> Thanks for your responses.  I've got a couple of comments.
> 
> > First the problem reported on the generated method for a collection
> > when
> > using a binding file is surely a bug of the binding file
> > implementation.
> > I will to take a look at it and see what I can do in a small time
> > frame.
> 
> Thanks for looking at it.  But could you clarify what the intended
> behavior is?  For the particular case we are talking about, I'd want
> the methods to be getClassMapping, etc., but I can see cases where a
> user might want to change only the name of the class -- not the name
of
> the field (or bean property or whatever your want to call it).  Is
> elementBinding/member the place to handle this?
> 
> > Concerning the simpleTypes, you are right it is not handled at all
by
> > the BindingComponent for the moment. If you take a look at the
> > 'binding'
> > XML Schema; you will see a room for defining a custom binding for
> > enumeration.
> 
> Ah yes, I saw that but I ignored it because it was commented out :).
> Looking more closely, it seems like it will be very powerful; perhaps
> even to the point of allowing the user to pick the field names for
each
> enumerated value?  That will be very nice.
> 
> I don't want to make you regret releasing your work-in-progress code,
> but I have a couple of things that I hope you'll consider in your
> implementation that aren't necessarily there in that commented-out
> block.
> 
> 1) It would be nice to have user-specifiable int or long values.  This
> will ease integration with JDO, since enumerations in databases are
> often handled through numeric foreign keys.  To make this useful,
there
> would also need to be generated a valueOf(int) method.  (For JDO
> integration, valueOf(int) would be a worthwhile addition to the source
> generator, even without the binding file.)
> 
> 2) For some cases, the enumeration generated by source generator is
> just fine.  So I hope you'll allow just the classname to be specified
> and have source generator create the enumeration.
> 
> 3) Much less important: it would be nice if the user could specify the
> name of the integer value field (and its accessor).  So instead of
type
> and getType, you could have, say, key and getKey.  Even less
important,
> but nice, would be to allow renaming of the the valueOf and toString
> methods.
> 
> I suppose I couldn't hurt to be more concrete, so I've attached a
> modified version of the enum section of binding.xsd that would support
> these features.  (It actually goes a bit further even than these three
> points.)

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
minimalist@exolab.org with a subject of:
	unsubscribe castor-dev

[prev in list] [next in list] [prev in thread] [next in thread]