cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Modeling annotations
Date Tue, 17 Jan 2017 15:17:33 GMT
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 <mgentry@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 <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
View raw message