Fair enough. While I would likely still avoid annotations in the model myself, I see where you are coming from.
It would be ideal if we could implement proper model extensions mechanism [1]. Then annotations, cdbimport specs, DB comments or any other arbitrary metadata can be done as independent optional modules. Andrus [1] https://lists.apache.org/thread.html/068029fd0197b1d55e2206bf666a84c5d24e20235fad3340901358de@%3Cdev.cayenne.apache.org%3E > On Jan 17, 2017, at 10:07 AM, Michael Gentry <mgen...@masslight.net> wrote: > > 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 <and...@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 <blackn...@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 <and...@objectstyle.org> >>> wrote: >>> >>>> [splitting annotations discussion in its own thread] >>>> >>>>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <and...@objectstyle.org> >>>> wrote: >>>>> >>>>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <blackn...@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 >>>> >>>> >> >>
