Hi Hugi, I haven't looked at this code in a while, but the framework was designed to use Persistent interface methods (readPropertyDirectly(..), writePropertyDirectly(..) and so on) to access object state, not reflection. With PropertyUtils and BeanAccessor we veered of that course. Here are a few BeanAccessor scenarios I dug up:
1. Persistent.readNestedProperty(..) for non-persistent properties 2. In-memory expression evaluation on POJOs 3. In-memory expression evaluation on Persistent objects 4. Reading "persistentState" property from a Persistent object Most apps hopefully don't care for #1 & #2. (those were cool features before Java streams. Now they are not very useful, and I would argue, out of scope for Cayenne. But they are not harmful either and can remain. #3 & #4 are just incorrect implementations and should be changed. We should not be using reflection where Persistent interface is present. I may be missing more cases, but you see where I am getting with this. After some cleanup, Cayenne would not care whether you call your getters "getXyz()" or "xyz()", and what you propose becomes purely a task of writing a custom template. And with 5.0 improvements, templates can be stored in your project and managed by the Modeler. So I suggest we focus on this cleanup. To quote The Matrix, when we are ready, we won't have to dodge bullets. Andrus > On Feb 2, 2025, at 7:38 AM, Hugi Thordarson <h...@karlmenn.is> wrote: > > Hi all! > > With 5.0 under development, I’d like to re-awaken an old proposal. > > When Cayenne generates classes, you’ll by default get JavaBean style prefixes > for attribute/relationship method names (“get” and “is”). I've never used > those and really don't want class generation to affect my method names, so I > use my own superclass template that does not include those prefixes and patch > in my own “BeanAccessor” (which is used by Cayenne to invoke class methods) > that assumes the prefixes are not present. > > Since I finally have time to do some Cayenne advocacy, I’m finding it feels > hacky to instruct folks to drop in a patch if they don’t want the method name > prefixes — so I’d like to propose that allowing classes to have non-prefixed > method names be made an option in the Cayenne core. > > I’d submit a pull request, but I don’t think I’m the best to propose how to > go about this. I change the behaviour myself by invoking > PropertyUtils.installAccessorFactory() with my own implementation ( > https://gist.github.com/hugithordarson/0367e4e9672df95559d331f072597662 ) > (that has to be in the package it is, since it relies on package protected > functionality from Cayenne) but I guess a more friendly way (if not a > configuration option) would be to make the BeanAccessor injectable. > > I don't think I’ll propose adding non-prefixed templates in the core as well > — adding one's own class generation template to a project feels much more > “normal” than dropping in a “hack class” to make things work. But just having > the functionality of NonPrefixedBeanAccessor available in core would be a > definite improvement. > > Furthermore, Carthago delenda something something :D > > Cheers, > - hugi
