Yes, that would be optimal and I attempted to make it a static inner class for precisely that reason, but it didn’t work. The BeanInfo class must reside within the same package as the class it’s supplementing and be called [ClassName]BeanInfo.
The best documentation I found on this is here: http://www-01.ibm.com/support/knowledgecenter/SSZND2_6.0.0/org.eclipse.ve.doc/topics/cve_beaninfo.html It mentions you can specify a search path for BeanInfo classes using Introspector.setSearchPath() but I wasn’t able to get it to work with inner classes. Cheers, - hugi > On 24. júl. 2015, at 17:01, John Huss <[email protected]> wrote: > > It would be pretty easy to generate it as a static inner class using the > entity template, then all the code is generated. Do the BeanInfo classes > have to be registered somewhere? > > On Fri, Jul 24, 2015 at 11:32 AM Hugi Thordarson <[email protected]> wrote: > >> Thanks John, implementing a BeanInfo class for eaach entity specifying >> method names actually works fine! >> The BeanInfo class can be associated with the superclass and placed in >> it’s package so it’s mostly out of the way, here’s an example >> implementation for an entity called “Product” containing a single property >> called “name”. >> >> https://gist.github.com/hugith/d1958e9ead2d3c1a390d >> >> Something of a hassle to have to do this for the entire object graph, >> though. >> >> Cheers, >> - hugi >> >> >> >>> On 24. júl. 2015, at 14:15, John Huss <[email protected]> wrote: >>> >>> In theory the bean spec allows you to specify a BeanInfo object that can >>> allow you to use different naming conventions, but in practice most >>> libraries cut corners and just assume "get" and "set". I'm not sure if >> it >>> works with Cayenne's Property and PropertyUtils however. For myself I >>> found it easier to just add the "get" prefix. >>> >>> John >>> >>> On Fri, Jul 24, 2015 at 9:11 AM Andrus Adamchik <[email protected]> >>> wrote: >>> >>>> Hi Hugi, >>>> >>>> 1. I can't think of anything inside Cayenne that would rely on a getter >>>> (Property.getFrom(..) is user-facing API that is not directly related to >>>> persistence). So you should be safe otherwise. >>>> >>>> 2. I am with Mike - if you can, better switch to JavaBean getters. >> You'll >>>> avoid lots of pain integrating with anything else in Java. >>>> >>>> Andrus >>>> >>>>> On Jul 24, 2015, at 3:32 PM, Michael Gentry <[email protected]> >>>> wrote: >>>>> >>>>> Hi Hugi, >>>>> >>>>> I don't know offhand everywhere in Cayenne that get* is required, but >>>>> Cayenne's default templates and expectations are that the JavaBeans >>>>> notation (get/set/is) prefixes will be used. Many other frameworks, >> such >>>>> as Apache Tapestry, work flawlessly with Cayenne because of the >> JavaBeans >>>>> notation, but would fail if get* were missing. >>>>> >>>>> I used to use EOF/Objective-C, too, and at first the get* seemed >>>> annoying, >>>>> but now within Eclipse it is easy to type "get" and let the >>>> autocompletion >>>>> popup show me my options, which you can't do without that prefix. >>>> Overall, >>>>> I think get* is a win because it is easier to find your getters and it >>>>> makes Cayenne work with other frameworks that expect the standard >>>> prefixes. >>>>> >>>>> mrg >>>>> >>>>> >>>>> On Fri, Jul 24, 2015 at 7:37 AM, Hugi Thordarson <[email protected]> >>>> wrote: >>>>> >>>>>> Hi all. >>>>>> >>>>>> I don’t use “get" prefixes on the accessors for attributes on my >>>>>> DataObjects. This has worked flawlessly until now, but I just stumbled >>>> onto >>>>>> a case where it will cause a failure inside Cayenne’s world, i.e. when >>>>>> attempting to access property values on objects using >>>>>> org.apache.cayenne.exp.Property.getFrom( someObject ). >>>>>> >>>>>> The method documentation explicitly states that a bean-style >> get-prefix >>>> is >>>>>> required, so this was to be expected. But I’m wondering if there are >>>> more >>>>>> places where Cayenne depends on it and if the requirement for the >> “get” >>>>>> prefix should be eliminated entirely within Cayenne’s universe? (I’m >>>> sure >>>>>> I’m not the only one who is not fond of using it) >>>>>> >>>>>> I got around this particular case by implementing my own “poor man’s >>>>>> KeyValueCoding” (for those of you familiar with EOF), but it would be >>>> nice >>>>>> not having to do something of that ilk. >>>>>> >>>>>> Cheers, >>>>>> - hugi >>>>>> >>>>>> // Hugi Thordarson >>>>>> // http://www.loftfar.is/ >>>>>> // s. 895-6688 >>>>>> >>>> >>>> >> >>
