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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > wrote: > > > >> [splitting annotations discussion in its own thread] > >> > >>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <[email protected]> > >> wrote: > >>> > >>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <[email protected]> > 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 > >> > >> > >
