Hi Hugi, My vote would be to do it right. There is a positive side effect that the entire reflection strategy suddenly becomes customizable.
Andrus > On Sep 25, 2018, at 7:11 AM, Hugi Thordarson <h...@karlmenn.is> wrote: > > Hi Andrus, and y'all. > > I've been looking into this and it seems like a rather large change to allow > something relatively simple (allowing DataObjects to have accessor methods > that don't start with a "get"-prefix). > > Would people be diametrically opposed to just changing BeanAccessor so that > it seeks for a non-prefixed method if a prefixed one isn't found? That > modification is minimal and shouldn't affect any current users, so I can > think of. > > Cheers, > - hugi > > > >> On 20 Sep 2018, at 16:08, Andrus Adamchik <and...@objectstyle.org> wrote: >> >> Hi Maik, >> >> In Cayenne a canonical way to override services is via DI. A PR that follows >> that approach has a good chance of acceptance. >> >> From a quick glance, I wonder if this new DI endpoint should be a factory of >> ClassDescriptorMap (which is currently lazily created inside >> EntityResolver). We can't make ClassDescriptorMap itself DI-managed as it >> depends on the mapping state, but a factory for it can be a DI singleton. >> Inside your custom factory (a few levels down actually) you can provide a >> subclass of BeanAccessor (maybe also via its own DI factory?). >> >> Andrus >> >> >>> On Sep 19, 2018, at 8:35 AM, Maik Musall <m...@selbstdenker.ag> wrote: >>> >>> Hi all, >>> >>> I'd like to pull up this discussion from one year ago again. I'm currently >>> running 4.0 and testing upgrading to 4.1 using field-based DataObjects, and >>> I'm hitting the hard-coded prefixes in BeanAccessor that prevent me from >>> proceeding. >>> >>> Yes, in theory I could sigh, yield, and use "get" prefixes, but not only do >>> I dislike introducing the "get" boilerplate everywhere. I am also somewhat >>> reluctant to make a refactoring touching some 800+ files in my project. To >>> be honest, I'd rather patch BeanAccessor to personal taste and deal with >>> the consequences. >>> >>> BeanAccessor is currently always called by it's constructor. In addition to >>> the options Hugi described in his original mail in this thread, I could >>> also imagine a way to modify this to be able to inject a custom Accessor >>> implementation as an alternative. What do you think? >>> >>> And… what would happen if someone would submit a pull request actually >>> implementing one of these options? :-) >>> >>> Cheers >>> Maik >>> >>> >>>> Am 26.09.2017 um 15:32 schrieb Hugi Thordarson <h...@karlmenn.is>: >>>> >>>> Hi Michael, >>>> >>>> thanks for an honest attempt to convince me. Hard sell, though. :) >>>> >>>> I use a lot of 3rd party libraries and I've only hit one time where using >>>> the bean spec was necessary — JasperReports. That was easily fixed by >>>> providing *BeanInfo classes, in accordance with the Bean spec. But Cayenne >>>> doesn't really follow the Java Bean Spec, it just hardcodes "is", "get" >>>> and "set". >>>> >>>> As for the Eclipse thing… Well. A standard DataObject already has five >>>> methods prefixed with "get" so that list is questionable. And I don't miss >>>> this functionality. >>>> >>>> I think it's important to note that the change I'm proposing would not >>>> affect those who choose to add the prefix. It just accommodates those of >>>> us who choose not to, thus expanding the audience of the framework. >>>> >>>> Cheers, >>>> - hugi >>>> >>>> >>>> >>>>> On 26 Sep 2017, at 12:01, Michael Gentry <blackn...@gmail.com> wrote: >>>>> >>>>> Hi Hugi, >>>>> >>>>> Let me try to sell you on the "get" prefix. :-) >>>>> >>>>> (I did a lot of WebObjects/EOF in the past, in Objective-C and Java, so I >>>>> understand the reluctance.) >>>>> >>>>> * The "get" prefix is part of the JavaBeans standard/contract. With the >>>>> exception of "is" for booleans (with a little "b"). >>>>> >>>>> * There are tons of Java frameworks out there that expect and utilize the >>>>> JavaBeans contract, so it is great for folding external frameworks into >>>>> your code. Or folding Cayenne into other frameworks, such as Tapestry. I >>>>> can specify Cayenne object/relationship paths in Tapestry (and other >>>>> frameworks) such as >>>>> t:value="currentItem.resourceSummary.grossCost.costs.continuingFootnote" >>>>> (real example). Since Tapestry expects the JavaBeans contract and Cayenne >>>>> provides it, this works flawlessly. >>>>> >>>>> * In Eclipse (and others, I'm sure) I can do anObject.get[pause or >>>>> control-space] and see all the getters associated with that object. >>>>> Without the get prefix, they are spread out a-z and therefore you can't >>>>> get >>>>> as concise a list. >>>>> >>>>> mrg >>>>> >>>>> >>>>> On Tue, Sep 26, 2017 at 7:02 AM, Hugi Thordarson <h...@karlmenn.is> wrote: >>>>> >>>>>> Hi all >>>>>> >>>>>> Touching on an old subject that has now become more important with >>>>>> field-based Data Objects. >>>>>> >>>>>> All of my DataObjects use accessor methods without the "get"-prefix. This >>>>>> was fine with Map Based data objects (where a MapAccessor would get >>>>>> property values by name), but now that my objects are field based, along >>>>>> comes BeanAccessor which is hardcoded to have every getter prefixed. >>>>>> >>>>>> I propose that BeanAccessor be modified to allow accessor methods without >>>>>> the "get"-prefix. Methods with "get" would get precedence, but if no >>>>>> method >>>>>> with a "get"-prefix exists, check for the existence of a method with only >>>>>> the property name. >>>>>> >>>>>> Although it's a minimal change in code, I realise it comes with a bit of >>>>>> potential baggage WRT testing. But this is not just to scratch a personal >>>>>> itch; once Cayenne 4.0 is out I want to start a large scale introduction >>>>>> of >>>>>> Cayenne to the EOF world where the get prefix is generally not liked and >>>>>> this change would have a big appeal. Besides, I'm not a big fan of the >>>>>> get-prefix myself, I find it a bit redundant :). >>>>>> >>>>>> An alternative would be to adhere to the Bean standard, and make >>>>>> BeanAccessor read bean meta information (usually specified in *BeanInfo >>>>>> classes) and get names of getter/setter methods from there. But that >>>>>> would >>>>>> be a much larger change than just checking for a method with propertyName >>>>>> if the getPropertyName method doesn't exist. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Cheers, >>>>>> - hugi >>>> >>> >> >
