Many thanks to all for the preceding effort and discussion. IMHO... I prefer option (A). From a user/ readability pov it seems to make more sense. The word "Object" is too anemic and in a wider sense conveys "Thing" aka "I can't think what to call it"
I like ViewModel to be a separate annotation rather than a "case class" of DomainObject. It is a separate object in its own right not just a property of an Entity. I don't like prefixing the other annotations with "Domain", would add unnecessary clutter and doesn't solve any problem (there are no serious conflicts, as discussed earlier) Best Regards Mike Burton (Sent from my iPhone) > On 31 Dec 2014, at 12:52, Branham, Jeremy [HR] <[email protected]> > wrote: > > I like the idea of @DomainEntity because it seems more descriptive, but I > guess that doesn’t fit well for ViewModels, hence the need for the > @ViewModel. > I also like prefixing the other annotations with 'Domain'. > > Is this the set that would be considered given option 'A' and the related > proposal? > > @DomainService > @DomainEntity and @DomainEntityLayout > @DomainProperty and @DomainPropertyLayout > @DomainCollection and @DomainCollectionLayout > @DomainAction and @DomainActionLayout > @DomainParameter and @DomainParameterLayout > @ViewModel and @ViewModelLayout > > > > Jeremy D. Branham > Tel: **DOTNET > > > -----Original Message----- > From: Dan Haywood [mailto:[email protected]] > Sent: Wednesday, December 31, 2014 1:05 AM > To: users > Subject: Simplifying annotation names > > Hi folks, > > Over on the [email protected] list we've been debating a couple of related > proposals on introducing some new annotations to make the framework overall > easier to learn and make features more discoverable. > > The main idea (as proposed in ISIS-970 [1]) is to replace the numerous > annotations with just two one for each feature, one to capture domain > semantics, and one for UI hints. And, of these, the latter is optional > because the xxx.layout.json file can always be used instead. > > Thus, for object members we are proposing: > > @Property and @PropertyLayout > @Collection and @CollectionLayout > @Action and @ActionLayout > @Parameter and @ParameterLayout. > > For services we have: > > @DomainService. > > For objects we have two alternatives, and opinion is currently split. > > option (A): > @DomainEntity and @DomainEntityLayout > with > @ViewModel and @ViewModelLayout > > or > > option (B) > @DomainObject and @DomainObjectLayout > > > With option (A), the two @XxxLayout annotations are basically identical, but > are provided for consistency. Remember that in most cases they won't be > used, with xxx.layout.json being used instead. > > With option (B), the concept of view models is relegated to an attribute of > @DomainObject, that is: > > @DomainObject(type = ENTITY | VIEW_MODEL) > > This is a slight simplification but is at the heart of the debate. > > So far, we've had 3 votes for option A and 4 votes for option B, see [2] > > So.... > ... are there any new opinions from anyone on option A vs option B? > > > > > ~~~~~~~~~~~~~~ > > A related proposal is to also rename the annotations for > @Property/@Collection/@Action etc, to add "Domain" as a prefix. > > This fits nicely with option (B), to give a full set of: > > @DomainService > @DomainObject and @DomainObjectLayout > @DomainProperty and @DomainPropertyLayout @DomainCollection and > @DomainCollectionLayout @DomainAction and @DomainActionLayout > @DomainParameter and @DomainParameterLayout > > For option (A), it probably doesn't make as much sense (unless we were to > have @ViewModelXxx equivalents for @Property/@Collection etc... which sounds > rather cumbersome to me). > > Any thoughts on this related proposal? > > Thanks > > Dan > > > > > [1] https://issues.apache.org/jira/browse/ISIS-970 > [2] http://isis.markmail.org/thread/272nnmh7kjvjwowl > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the sole > use of the recipient(s). Any use by others is prohibited. If you are not the > intended recipient, please contact the sender and delete all copies of the > message.
