cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <johnth...@gmail.com>
Subject Re: get-prefix in DataObjects
Date Fri, 24 Jul 2015 17:01:09 GMT
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 <hugi@karlmenn.is> 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 <johnthuss@gmail.com> 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 <andrus@objectstyle.org>
> > 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 <mgentry@masslight.net>
> >> 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 <hugi@karlmenn.is>
> >> 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
> >>>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message