>> "Should Cayenne by default work without prefixed accessors". > > My answer to this : "By default, no. As a fallback or a custom strategy, > possibly."
Fair enough. > I actually agree about Java beans. They are almost irrelevant now. And I wish > Java gets "data classes" and some transparent form of "properties". > > As things stand now though, there's no common established alternative based > on a naming convention that we can safely hardcode without causing grief for > someone because they didn't expect that their method would be called when > evaluating expressions. Hence my preference for a DI fix. > > So how about this... Unless someone else steps in by then, let me brainstorm > it with Nikita a couple of weeks from now and see if we can do a DI solution. > It is not nearly as involved as it appears. Sounds awesome :). I wish I could be the one to step forward given I'm the one raising a fuss, but after looking at the changes involved and given my knowledge, I'm a bit hesitant to start hacking away on such a core part of Cayenne's design at this time. Cheers, - hugi > > Andrus > > >> On Sep 25, 2018, at 9:59 AM, Hugi Thordarson <h...@karlmenn.is> wrote: >> >> Hi Andrus and thanks for the reply, >> >> allowing replacement of the entire reflection strategy is certainly nice and >> would allow me to make the customizations I need. >> >> However, if it's OK with you, rather than discuss implementation details, >> I'd like to take two steps back and revert to the more philosophical design >> question of: >> >> "Should Cayenne by default work without prefixed accessors". >> >> What is there to be lost or gained from keeping or abandoning the >> prefix-requirement? >> >> I believe I can safely assert that Cayenne works fine without accessor >> prefixes, since I've used it that way on dozens of projects, so it looks >> like a somewhat arbitrary limitation. It's only with the introduction of >> field based DOs that we get a problem in a very isolated part of the >> framework. >> >> It seems to me that the java ecosystem is moving towards more modern API >> design—we've even got the architect of the Java language calling the >> bean-style "at best a questionable -- and certainly overused -- API naming >> convention" [http://cr.openjdk.java.net/~briangoetz/amber/datum.html >> <http://cr.openjdk.java.net/~briangoetz/amber/datum.html>] (pardon the >> appeal to authority, but considering where it comes from, it's probably a >> good barometer for where java language and API design is headed). >> >> I'd say that the framework would be well served and future-proofed by >> dropping the requirement for hard-coded accessor prefixes as a baked in >> requirement. >> >> Cheers, >> - hugi >> >> >> >>> On 25 Sep 2018, at 11:15, Andrus Adamchik <and...@objectstyle.org> wrote: >>> >>> 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >
