On 31 December 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
>
>
Possibly, though for view models it would result in their properties etc
being annotated @DomainProperty etc.  Given that one of the arguments for
keeping @ViewModel separate is that they belong to the application-layer
(rather than domain-layer) then having @DomainXxx could be thought of as
confusing.

Dan


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

Reply via email to