Stephen, I am not saying 'let's do this on the JDO side of things' only ... ;-). Having said that, here's some random observations:
* I have been and still am quite busy (together with Ralf) preparing the 1.0 M2 release for either tomorrow and/or Friday. In addition, we have scheduled a 1.0M3 in two/three weeks time, as we want to go towards a 1.0 final in an iterative way. * As you have probably noticed yourself, there's a lot of XML bugs out there that imho should be addressed first before going about implementing a new feature (as interesting it might seem). * Having a little bit more resources, I thought that we could start on the JDO side, find a possible way (e.g. via extending the mapping file as suggested by yourself) ... and hence allow you (the XML side in general) to benefit from the lessons learned. Bear in mind that both Castor XML and JDO have the castor.mapping package in common, as both areas (can( use a mapping file. * For some folks, having to define a new property (to be named) on a field by field base might seem tedious and unnecessary, if bespoke property could be defined on e.g. the class mapping level. Some others might prefer an approach where there's a default (either way) for the class level, and for individual fields the would want to override that definition. Just my 0.02 cents worth ... Werner Stephen Bash wrote: > Werner- > > Any reason you're interested in JDO side first? I'm only using XML, and > I would also like to see this capability added... That being said, I'm > not sure I have the time to work up the patch for XML, but I guess I can > look at it when I do find some time. > > And my personal opinion would be a modification to the mapping file > specifying that Castor should use reflection to get at the field (I'm > not sure if there is any way to do this other than reflection). The > mapping file has the advantage that I can define this property on a > field by field basis. > > Stephen > > > On 2/1/06, *Werner Guttmann* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Based upon this little discussion, is anybody willing to come up with an > initial patch (specific to Castor JDO initially, if possible) ? That > patch should take care of the following tasks: > > * identify the contract (if required at all); iow, define a way that > users can instruct Castor to access private getter/setters. This could > be either a configuration option via castor.properties, or be in form of > an amendment to the mapping file. > * identify the main areas of change (iow, include some meaningful > (though minimal) documentation. > * make the necessary changes in for of a unified patch. > > Having said that, I think that I'd like to see a initial contribution > from somebody else than me and/or Ralf ... ;-). > > l4l > Werner > > Gregory Block wrote: > > > > On 25 Jan 2006, at 20:08, Jay Goldman wrote: > > > >> IMHO this gives castor license to cross the public/private 'barrier' > >> when the user of castor has asked for this behavior ( i.e., via > >> direct="true") just as java serialization allows for the setting of > >> private data. > > > > > > *cheer* > > > > 150% behind you. :) > > > > ------------------------------------------------- > > If you wish to unsubscribe from this list, please send an empty > message > > to the following address: > > > > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > ------------------------------------------------- > > > > > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > ------------------------------------------------- > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
