Hi Rhett, I agree with your posting. I never wanted those to be separated in the first place, but I left the decision up to Thomas and the JDO team at the time since I felt they knew more about what they were trying to achieve. My initial feeling was that instead of coming up with separate ways of handling the mappings and descriptors we could have a core set that each part of Castor (including the LDAP/DAX and DTX portions which no longer exist) would share. Each sub-project would then have it's own specific information which could be obtained from the core descriptors/handlers. Unfortunately this wasn't the approach the JDO developers wanted to take at the time and as they had other visions and some "major refactoring" so they wanted a clean separation between the sub-projects. The problem is that much of the "refactoring" Thomas (and others) wanted to do, never got done, but not necessarily to his fault. His primary focus at work had changed and he no longer was able to work on Castor as part of his job and decided that dedicating his after-work hours to Castor JDO was not how he wanted to spend his time.
Luckily we found Bruce who has been a great contributor to the project and took over the Castor JDO lead. Bruce and I have been working together, when we have time, to try and bring Castor JDO and Castor XML into more harmony with each other. I'd definately like to see the ClassMolder/FieldMolder stuff disappear if possible and just rely on the original FieldHandler/ClassDescriptor/FieldDescriptor code. Or make them wrappers of if possible as you suggested in your posting. Since the changes would primarily be on the JDO side, this will take effort from the JDO contributors and need the approval of Bruce, whom I am sure would agree that clean-up needs to be done. It's simply a matter of who and when. If it's something your willing to help then that would be great. Thanks, --Keith Rhett Sutphin wrote: > > Hi, > > An age (6 mos) ago, before I had ever heard of castor, there was a > discussion on this list about why there are separate FieldMolder and > FieldHandler (etc.) classes when they appear to do largely the same > thing. (Here's the original message: > http://castor.exolab.org/list-archive/msg08538.html ; follow Keith's > reply for the stuff I'm taking about.) I've read through it before and > I just have again, and I'm still not convinced that it is a reasonable > separation. > > Now that I am trying to add a new feature to castor (enums in JDO, bug > 1157), I have become convinced that this decision is the major reason > why there are always posts from Bruce and Keith saying "that feature > only works in XML" (or JDO) when it is not apparent to an independent > observer why that needs to be the case. So I'm going to revisit the > main argument in that thread and hopefully get some responses. Maybe > we can come up with a modified design that will make it possible to > develop for JDO and XML concurrently. > > The main argument that Thomas Yip put forward is that FieldHandler and > FieldMolder need to be separate... > > Thomas Yip, 18 June 2002, > http://castor.exolab.org/list-archive/msg08551.html : > > Because two parts evolves, and each adds significant amount of > specific mapping that doesn't make sense for the other. > > > > We have two choices. Either we make the mapping loading to load the > combined set of all mapping. > > > > But, I believed it would be better for each part to evolve if we > don't share the same loading mechanism. > > With all due respect, this is bogus for a couple of reasons. First, > while the needs of JDO and XML differ in the details, their core > functionality is exactly the same: take a java class instance and > translate its fields into another, strictly defined format. Take an > instance in this strictly defined format and translate it back into a > java instance. (Their inherent similarity is certainly why they are > wrapped together in the same codebase with the same project name and > why their mapping files _use the same schema_.) > > This is why object-oriented programming was invented. You define core > functionality and layer additional classes on top in order to achieve > specific functionality. It appears that castor was originally designed > this way: note, for instance, MappingLoader which is elaborated by > JDOMappingLoader and XMLMappingLoader to handle the two sides' > particular needs. > > Second, even with this ill-advised dichotomization, fully half of JDO's > functionality is achieved using what must be called the "XML" side. > JDO analyzes java instances just like XML does, using FieldHandlers > (and FieldDescriptors and ClassDescriptors), and doesn't seem to be any > the worse for wear for doing so. JDO uses FieldMolders (and > ClassMolders, etc.) only for loading from the database. So this means > that maintaining JDO is twice as complex and failure-prone -- and > that's just for one aspect (instantiating on load / preparing to > store). For another example: I am fairly certain that bug 1093 ( > http://bugzilla.exolab.org/show_bug.cgi?id=1093 ) arises because JDO > loading uses a seemingly-redundant separate mechanism (DatingService) > for matching fields with their types than XML. > > If JDO could use of XML's FieldHandlers and associated classes for both > loading and storing, it would only be for the best. The same logic > could be used to custom-prepare relational persistence as is used for > XML instances. It would simplify adding new types -- for instance, as > relates to JDO integration with the source generator. > > For all that, I'm not going to suggest a particularly radical solution. > Going forward, we are all constrained to work with what we have -- I'm > sure no one could volunteer to take two weeks or a month to refactor > the core of castor -- but I think we could have something better than > the mixed bag that exists at present. > > So: It seems to me that, better or worse, we are stuck with > ClassMolders and FieldMolders for the moment. But in the short term, I > can't see why the FieldMolders couldn't just be a wrapper around a > FieldHandler. They do the same thing (provide a way to get/set a value > from/to the field they describe), but FieldHandlers are much more > sophisticated (by dint of being in the more-developed XML side, it > seems to me) and have the benefit of being user-specifiable. > > A little further down the line, perhaps we could look at changing the > code that resolves FieldHandlers to class instances such that it could > be used by both halves of castor. Like I said above, I can't tell if > there is some genuinely different behavior between the classes that do > this on the XML side vs. the JDO side (comments appreciated), but it > can't be _that_ different. > > I'd be happy to contribute to one or both of these improvements, but > I'd like to hear some comments from the more experienced castor > developers first. Am I missing something important? Is this the > right, incremental way to approach this? Like I said before, I've only > been using castor for a short time (under three months), so it is not > impossible that I'm going of half-cocked and there's a better way I > could be spending my time. Whatever the case, please let me know. > > Thanks for reading though that whole thing. I think its an important > point and potentially something that could help fix a lot of bugs by > either making them more visible or eliminating their homes. Anyway, > like I've said before, please don't construe this as an attack. Castor > is good software. I don't wish to give offense, only to help make it > 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] > > ----------------------------------------------------------- > 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
