cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <mgen...@masslight.net>
Subject Re: Modeling annotations
Date Tue, 17 Jan 2017 15:07:35 GMT
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
> >>
> >>
>
>

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