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 >> >>
