Hi Arnaud, Thanks for your responses. I've got a couple of comments.
First the problem reported on the generated method for a collection whenThanks 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?
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.
Concerning the simpleTypes, you are right it is not handled at all byAh 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.
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.
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.)
enumBindingType_mod
Description: Binary data
In order to move over to using mapping.xsd+mapping-binding.xml for generating the mapping object model, we'll need at least point two (renaming enum classes) functioning. How long do you think it will be before you could have an implementation of something like that?
Thanks a lot for all your work.
Rhett
On Tuesday, December 24, 2002, at 04:39 AM, Arnaud Blandin wrote:
Hi Rhett,
Thanks for your feedback; I will try to cover your questions here.
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.
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.
It is on my to-do list and it will be next step in the re-factoring of
the SourceGenerator and yes it will allow users to get rid of the
'.types' package.
However for backward compatibility purposes, the '.types' package
generation will be provided as a default behavior but the implementation
will definitely be neater.
I wish you a merry Christmas as for all the Castor fans of that list
:+),
Arnaud
-----Original Message----- From: Rhett Sutphin [mailto:[EMAIL PROTECTED]] Sent: Monday, December 23, 2002 9:51 PM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Source Generator & mapping-binding Hi all, Sorry for all the messages. This will be my last self-reply on this topic. On Monday, December 23, 2002, at 10:37 AM, Rhett Sutphin wrote:<!-- or name="@collection" or name="field/collection" or name="field/@collection" --> <cbf:attributeBinding name="collection"> <cbf:java-class name="CollectionType"/> </cbf:attributeBinding> I also tried the same thing nested inside the elementBinding for field. In every case, I still get FieldMappingCollectionType, but source generator doesn't give any errors. Advice would be >appreciated.So the problem seems to be that the binding file is 100% ignored for simple types. Primary evidence: SourceFactory#createSourceCode(SimpleType, SGStateInfo) does not ever refer to _bindingComponent. There is also this snippet from binding.xsd (the source generator binding file schema): Attribute cannot be mapped to class, the reader of a binding file will take care that class or interface are not used for component whose xml-type is attribute. This is only mostly true :). Attributes are often of enumeratedtypes,and changing the class name (or package) of the generated enum is a reasonable thing to want to do. As a hack, I tried doing _bindingComponent.getJavaClassName to loadthebinding-file-specified class name for an enum. It works -- but thenitoverrides the standard automatic naming for any enum which whose name is _not_ specified in the binding file. This is because _bindingComponent.getJavaClassName makes up a name if none isspecifiedin the binding file (instead of returning null), and it happens to be different from the one SourceFactory makes up. Near as I can tell, there is no way to get at the actual binding object from SourceFactory (all accessors of member objects which might expose it are private or protected), so there's no way to see if the java-class element was specified. Am I overlooking something? On a tangentially related topic: Once the source generator binding file can handle java-class on simple types, can we consider removing/disabling/making optional the uglyhackof putting enum classes into a separate package with a hardcoded name (i.e., 'types')? After all, with the binding file, the classes can be named anything and put in any package. There's no need to treat any particular type of class specially. Since I've spent all morning sending what might be construed as semi-harsh criticism of source generator, I'd like to reiterate that I think it is almost entirely a very cool and useful piece of software. I'm just trying to help make it a little better. Rhett ===================================================== | Rhett Sutphin | Research Assistant (Software) | Coordinated Laboratory for Computational Genomics | and the Center for Macular Degeneration | University of Iowa - Iowa City, IA 52242 - USA | 4111 MEBRF - email: [EMAIL PROTECTED] ===================================================== On Monday, December 23, 2002, at 10:37 AM, Rhett Sutphin wrote:I reply to myself. On Monday, December 23, 2002, at 09:51 AM, Rhett Sutphin wrote:[BTW, when I generated the full mapping object model from theschema,I got a whole bunch of classes (including the amusingly named CacheTypeTypeType) that aren't in CVS. They are mostly typesafe enumerations. It makes me worry that this change is going to substantially change the API. But I haven't gotten castor to build yet because of the aforementioned problem, so I can't say for certain.]After a closer look, these appear to be enums that exist in CVS,justwith different names. So the binding file will have to be expandedtocover them, too. I made a couple of attempts, but none were successful. As an example, take the attribute "collection" on the "field"element.In CVS, it is represented by a typesafe enum class called CollectionType. By default, the current source generator creates a class called FieldMappingCollectionType. Here's what I've tried: <!-- or name="@collection" or name="field/collection" or name="field/@collection" --> <cbf:attributeBinding name="collection"> <cbf:java-class name="CollectionType"/> </cbf:attributeBinding> I also tried the same thing nested inside the elementBinding for field. In every case, I still get FieldMappingCollectionType, but source generator doesn't give any errors. Advice would be >appreciated.Rhett----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
