You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2014/12/31 08:04:49 UTC
Simplifying annotation names
Hi folks,
Over on the dev@isis.a.o 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
Re: Simplifying annotation names
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 31 December 2014 at 12:52, Branham, Jeremy [HR] <
Jeremy.D.Branham@sprint.com> 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:dan@haywood-associates.co.uk]
> Sent: Wednesday, December 31, 2014 1:05 AM
> To: users
> Subject: Simplifying annotation names
>
> Hi folks,
>
> Over on the dev@isis.a.o 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.
>
RE: Simplifying annotation names
Posted by "Branham, Jeremy [HR]" <Je...@sprint.com>.
> 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)
Good point; and as Dan pointed out in another email, it could create confusion having @Domain* in the ViewModels.
I also prefer option (A) with no 'Domain' prefix on the property annotations.
Jeremy D. Branham
Tel: **DOTNET
-----Original Message-----
From: Mike Burton [mailto:mikeb@mycosystems.co.uk]
Sent: Wednesday, December 31, 2014 7:29 AM
To: users@isis.apache.org
Subject: Re: Simplifying annotation names
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] <Je...@sprint.com> 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:dan@haywood-associates.co.uk]
> Sent: Wednesday, December 31, 2014 1:05 AM
> To: users
> Subject: Simplifying annotation names
>
> Hi folks,
>
> Over on the dev@isis.a.o 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.
________________________________
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.
Re: Simplifying annotation names
Posted by Mike Burton <mi...@mycosystems.co.uk>.
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] <Je...@sprint.com> 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:dan@haywood-associates.co.uk]
> Sent: Wednesday, December 31, 2014 1:05 AM
> To: users
> Subject: Simplifying annotation names
>
> Hi folks,
>
> Over on the dev@isis.a.o 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.
RE: Simplifying annotation names
Posted by "Branham, Jeremy [HR]" <Je...@sprint.com>.
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:dan@haywood-associates.co.uk]
Sent: Wednesday, December 31, 2014 1:05 AM
To: users
Subject: Simplifying annotation names
Hi folks,
Over on the dev@isis.a.o 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.