On 30 December 2014 at 23:44, David Tildesley <davo...@yahoo.co.nz> wrote:
> +1 for the counter proposal (although I would suggest cloning/deriving > "@DomainObjectLayout" to "@ViewModelLayout" etc. so that "Domain*" tags are > not used in ViewModel - less confusing). > > On a different thread to dev@ I also made a related proposal that @Property, @Collection, @Action etc be renamed to @DomainProperty, @DomainCollection, @DomainAction etc... the primary reason being that clashes with @Collection clashes with java.util.Collection, plus I like the idea of all Isis-related annotations starting with an @DomainXxx prefix. No one's commented on that, yet. Given your preference of @ViewModel and reserving "@Domain" to be strictly for domain layer concepts, would I be right to guess you wouldn't be in favour of adding "Domain" as a prefix to all those annotations? > On Tuesday, 30 December 2014 3:07 AM, Dan Haywood < > d...@haywood-associates.co.uk> wrote: > > > On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < > o....@gesconsultor.com> wrote: > > > Ok. > > > > So let's raise some questions/doubts :) > > > > *** @DomainObject *** > > > > Is a ViewModel a DomainObject at all ? > > > > > it's a good question, and I've debated it myself. Let me lay out my > thinking on this so far and see if we can collectively come to a view on > this. > > First thing to note is that there are two "varieties" of view models (even > though the implementation is identical) > > - those that are part of the domain layer and are, conceptually at least, > entities, but where the persistence is managed outside of Isis. An example > is a document in a CMS > - those that are part of the application layer, and represent a view on top > of one or more entities. > > Of course, we expect an application layer to depend on the domain layer and > not vice versa, but even so, because some view models are conceptually > entities I suspect that in a typical Isis application it will be reasonable > to allow JDO-managed domain entities to interact with externally-managed > view model entities. > > > Because of this, I've been thinking of "DomainObject" as being a superset > of both entities and view models. > > > > > > I would consider them as a different kind, so the @ViewModel annotation > > shouldn't be deleted. > > > > You are certainly right that quite a few of the features in @DomainObject > don't apply to view models (even if conceptually they are entities)... > because we rely on JDO to implement. Specifically: > > - auditing... requires JDO so doesn't apply to view models > - publishing ... requires JDO so doesn't apply to view models > - bounded = not sure... even though doesn't depend on JDO, suspect that it > isn't supported for view models > > - autoComplete ... is supported for view models > - editing ... is supported so long as the ViewModel.Cloneable interface is > also implemented. I can foresee this restriction being lifted in the > future > - objectType ... is supported for view models (used as REST URLs) > > > > > > > Also, perhaps we can introduce Isis platform logic like not > > "saving/persisting" view models, etc. If that would be the case, the > > "editing" and "editingDisabledReason" at least might not have any sense. > > > > > Not sure I understand this point. But at any rate, given that some view > models are basically externally-managed entities, the semantics of > "saving/persisting" would also apply. > > > > > > > > > If so, I would better align with DDD naming conventions, in order to gain > > acceptance. > > > > So, names should be @Entity or @DomainEntity (for avoiding name collision > > with JPA) - instead of @DomainObject -. > > > > > I did consider @DomainEntity, but as I say, sometimes view models act like > entities. I do quite like it though. > > I have a counter-proposal, see below. > > > > > I like the @DomainService name, as it can act as a DDD Factory and/or > > Repository. > > > > > > As currently there's no "special" support for AggregateRoots or > > ValueObjects, no more annotations are needed. > > > > > Sounds like a vote to deprecate. Jeroen has said the same thing. Perhaps > they should be deleted in v2.0 and reappear, if we want them back, in v3.0. > > > > > So the proposed set would be: > > • @ViewModel and @ViewModelLayout > > • @DomainService and @DomainServiceLayout > > • @DomainEntity and @DomainEntityLayout > > • @Property and @PropertyLayout > > • @Collection and @CollectionLayout > > • @Action and @ActionLayout > > • @Parameter and @ParameterLayout > > > > > > > Here's my counter-proposal. It's not as symmetrical as before, but perhaps > is less confusing overall: > > * replace @DomainObject(viewModel=false) with > @DomainEntity(persistence=JDO) > ... this would be the default > * replace @DomainObject(viewModel=true) with > @DomainEntity(persistence=EXTERNAL) > ... for view models representing externally-persisted entities. In the > Javadoc, say that auditing, publishing and bounded are not supported for > these > * keep @ViewModel > ... extend to include the non-entity stuff from @DomainObject that does > apply (basically, I think that's just "objectType" ) > ... the intention being that this is used for application-layer views. > > keep @DomainObjectLayout, because everything in it applies equally to both > view models (either variety) and JDO entities. > > > I'll reply on your points on @Property and @Parameter separately. > > Thx > Dan > > > > > > >
