On 29 December 2014 at 14:27, Jeroen van der Wal <jer...@stromboli.it>
wrote:
> I prefer the symmetrical approach: replace @ViewModel with
> @DomainEntity(persistence=NEVER)?
>
>
I'm guessing you mean to retain @DomainObject rather than @DomainEntity?
Or how about:
@DomainObject(
type = ENTITY | EXTERNAL_ENTITY | VIEW_MODEL
)
for JDO-managed entities, externally managed view mdel entities, and
application-layer view models respectively.
We could also have a meta model validator that ensures that the programmer
doesn't try to specify incompatible attributes,
eg: auditing=ENABLED and the type is EXTERNAL_ENTITY or VIEW_MODEL will
throw a metamodel validation exception.
Dan
> Cheers,
>
> Jeroen
>
> PS Dan: do you still have that Google apps sheet with all annotations
> floating around?
>
>
Um, I don't remember doing one. But I did update the Isis website, and
it's in tabular form, perhaps that's what you mean?
http://isis.apache.org/reference/recognized-annotations/about.html
>
> On Mon, Dec 29, 2014 at 3:05 PM, 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
> >
> >
> > >
> >
>
