Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
MIME-Version: 1.0
In-Reply-To: <D270127A-DB1D-4AA9-9A65-F1B0544359A8@objectstyle.org>
References: <67c9aa19b3cd4fa99e0a521428ae1bc1@git.apache.org>
 <BE362DBA-2B6E-4662-9EA5-96B168456D28@objectstyle.org> <CAOy5kzOgVCkJd2B1YQqHTxLmDw0ndamJAGN7xvnd-u5pvZN62g@mail.gmail.com>
 <8970F5AF-F807-4427-8775-1D025137F807@objectstyle.org> <6A6409B8-A54C-461B-ADC3-7442917B3A9E@objectstyle.org>
 <CAOy5kzMBNQx_+KnmH0ujJMRDfxEfiUWTecOJTWtQmFm_TY9iEw@mail.gmail.com> <D270127A-DB1D-4AA9-9A65-F1B0544359A8@objectstyle.org>
From: Michael Gentry <mgentry@masslight.net>
Date: Tue, 17 Jan 2017 10:07:35 -0500
Message-ID: <CAA-upzpEugoY8myV_eXy+nBpvSou7AN-=Osu=COo_Zz-WLULqQ@mail.gmail.com>
Subject: Re: Modeling annotations
To: Cayenne Developers <dev@cayenne.apache.org>
Content-Type: multipart/alternative; boundary=001a1146d90a3e589c05464baafd
archived-at: Tue, 17 Jan 2017 15:08:02 -0000

--001a1146d90a3e589c05464baafd
Content-Type: text/plain; charset=UTF-8

I don't think that will allow enough granularity or control.  For example,
there are certain fields we don't want exposed, etc.  A custom template
would apply the same annotation everywhere.  That's why in the new CM I was
adding annotation support on everything.


On Tue, Jan 17, 2017 at 9:58 AM, Andrus Adamchik <andrus@objectstyle.org>
wrote:

> I wonder if "regular" things like JAXB annotations can be generated via a
> custom template?
>
> Andrus
>
> > On Jan 16, 2017, at 11:20 AM, Michael Gentry <blacknext@gmail.com>
> wrote:
> >
> > My initial desire for annotation support was to allow for JAXB
> annotations (
> > http://www.techferry.com/articles/jaxb-annotations.html), but of course
> it
> > could be used for other purposes.  I'm not sure how much IDE refactoring
> > would take place in this arena.  I concede renaming "MyHandler" could be
> > problematic, or at least surprising -- hopefully you'd notice the _
> > superclasses had unexpected changes.
> >
> > I really want to be able to specify annotations, but I'd also hate to
> lose
> > the generation gap pattern and "uglify" the subclasses (if they even
> > existed at that point) with something like this:
> >
> >    @MyA {
> >        handler = com.foo.MyHandler,
> >        types = {"a", "b", "c"},
> >        name = "foo"
> >    }
> >    @Generated // By Cayenne - DO NOT EDIT
> >    @XmlElement // I intentionally put this annotation after @Generated to
> > maybe cause problems...
> >    public String getNotes() {
> >        return (String)readProperty(NOTES_PROPERTY);
> >    }
> > [repeat]
> >
> > You'd also need to "protect" NOTES_PROPERTY as well, all the relationship
> > methods, etc.
> >
> > I can see it being quite difficult to merge without causing problems,
> too.
> > You'd also need to properly parse the method to find the end -- people
> can
> > have custom templates where more logic is added into the generated
> methods,
> > so you can't just skip to the next }.  Also, how do you track renames?
> If
> > someone changed "notes" in CM to "note" and regenerated classes, would it
> > create a new getter/setter for "note", delete "notes" and all annotations
> > on it, losing the annotations you had intended for "notes" (which is now
> > "note")?  This would also be quite surprising for most users.
> >
> > Thanks,
> >
> > mrg
> >
> >
> > On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <andrus@objectstyle.org>
> > wrote:
> >
> >> [splitting annotations discussion in its own thread]
> >>
> >>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <andrus@objectstyle.org>
> >> wrote:
> >>>
> >>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <blacknext@gmail.com>
> wrote:
> >>>> We had looked at overriding getters/setters for annotations, but we
> >> didn't
> >>>> want to do that 1000s of times, so we gave up.
> >>>> I see value in the
> >>>> superclass being able to have annotations along with JavaDocs for
> >> various
> >>>> attributes and relationships, plus the class itself.  The superclass
> is
> >>>> essentially maintained outside of the IDE currently, anyway (you may
> >> look
> >>>> at the code, but you don't edit it), so I don't think it'll be too
> bad.
> >>
> >>> But how does this save us work creating annotations? If you had to
> >> override 1000's of methods, then you will have to create 1000's of
> >> annotations in the Modeler as well to achieve the same effect. The only
> way
> >> to cut down on the number of (repeating) annotations is if they are are
> all
> >> applied to the same properties of different entities. Then they can be
> >> moved to a separate interface (or a superclass common to all entities),
> all
> >> outside the Modeler and within the IDE.
> >>
> >> More on why annotations being on the IDE side is important ...
> Annotations
> >> do not have to be trivial. They may have a bunch of references to other
> >> code. So taking them out of reach of the IDE refactoring is really
> >> inconvenient. E.g.:
> >>
> >> @MyA {
> >>  handler = com.foo.MyHandler,
> >>  types = {"a", "b", "c"},
> >>  name = "foo"
> >> }
> >> class MyClass {}
> >>
> >> So here if you say rename "MyHandler", you have a good chance of missing
> >> it in the XML. We've seen this problem repeatedly with Listener classes
> >> mapped in the Modeler, which led us to remove Listener functionality
> from
> >> the Modeler completely. This generally made me extremely wary of keeping
> >> non-ORM pieces of code in the XML.
> >>
> >> So perhaps there's another solution for annotations? Such as replacing
> the
> >> "generation gap" pattern in the future versions with smarter "merging"
> code
> >> generators (e.g. using @javax.annotation.Generated to tell the code
> >> generated by us from the code created by the user).
> >>
> >> Andrus
> >>
> >>
>
>

--001a1146d90a3e589c05464baafd--