For me also. It is a good consensus.
Thanks,
David.
Sent from Yahoo Mail on Android
This is a good compromise IMHO.
Jeremy D. Branham
Tel: **DOTNET
-Original Message-
From: Dan Haywood [mailto:d...@haywood-associates.co.uk]
Sent: Saturday, January 03, 2015 7:27 AM
To: users
Cc: dev@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a
ent: Saturday, January 03, 2015 7:27 AM
> > To: users
> > Cc: dev@isis.apache.org
> > Subject: Re: ISIS-970 ... (new annotations) please review if you get a
> chance...
> >
> >> On 3 January 2015 at 13:14, Jeroen van der Wal
> wrote:
> >>
> >>
.co.uk]
> Sent: Saturday, January 03, 2015 7:27 AM
> To: users
> Cc: dev@isis.apache.org
> Subject: Re: ISIS-970 ... (new annotations) please review if you get a
> chance...
>
>> On 3 January 2015 at 13:14, Jeroen van der Wal wrote:
>>
>>
>> I have o
Sounds good.
Mike
> On 3 Jan 2015, at 13:27, Dan Haywood wrote:
>
>> On 3 January 2015 at 13:14, Jeroen van der Wal wrote:
>>
>>
>> I have one more thought: since @ViewModel and @DomainObject(nature=UI_VIEW)
>> are the same concepts it might be more intuitive to use
>> @DomainObject(natur
On 3 January 2015 at 13:14, Jeroen van der Wal wrote:
>
> I have one more thought: since @ViewModel and @DomainObject(nature=UI_VIEW)
> are the same concepts it might be more intuitive to use
> @DomainObject(nature=VIEW_MODEL)
>
>
Yes, that probably does make sense; we are just providing two equ
Thank you Dan for your excellent recap and proposal.
I have one more thought: since @ViewModel and @DomainObject(nature=UI_VIEW)
are the same concepts it might be more intuitive to use
@DomainObject(nature=VIEW_MODEL)
On Sat, Jan 3, 2015 at 1:27 PM, Dan Haywood
wrote:
> On 3 January 2015 at 12
On 3 January 2015 at 12:16, GESCONSULTOR wrote:
>
>
> Just some thoughts. i don't see compatible an option called "UI_VIEW" in a
> "domain" object.
>
> Perhaps just "VIEW"?
>
>
The reason I'm suggesting UI_VIEW is that (as you stated yourself) "VIEW"
is overloaded it might refer to a UI/app-l
Bou <
>>> o@gesconsultor.com> wrote:
>>>
>>>
>>> Hi folks!!
>>>
>>> Happy New Year to all those following the Gregorian Calendar !!!
>>>
>>>
>>> As David mentions, we can think about ViewModels to be like
al systems entities.
> >
> > As Isis managed Properties/Collections can belong to any class of this
> Bounded Context / Domain or External Systems Domains objects (being a
> DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the
> ApplicationLayer, a ViewModel
>
> Oscar
>
>
>
>
>
>> El 31/12/2014, a las 23:40, Branham, Jeremy [HR]
>> escribió:
>>
>> At least it wasn’t DOA =]
>>
>> That helps me understand the evolution of Isis better, and It makes sense
>> the PD would never depen
D layer and have a direct
>> integration from UI layer to SI layer (e.g fetch a controlled value list
>> from some other system) although I would say that ISIS negates the need to
>> do this anyway by lowering development cost.
>> A step in the right direction is to first so
his correctly?
Jeremy D. Branham
Tel: **DOTNET
-----Original Message-
From: David Tildesley [mailto:davo...@yahoo.co.nz]
Sent: Wednesday, December 31, 2014 4:36 PM
To: dev@isis.apache.org; us...@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
Sorry
...@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled
with IoC in my brain).
On Thursday, 1 January 2015 11:04 AM, David Tildesley
wrote:
Hi Jeremy,
The intention of "View
t; Jeremy D. Branham
> Tel: **DOTNET
>
>
> -Original Message-
> From: David Tildesley [mailto:davo...@yahoo.co.nz]
> Sent: Wednesday, December 31, 2014 4:36 PM
> To: dev@isis.apache.org; us...@isis.apache.org
> Subject: Re: ISIS-970 ... (new annotations) please revi
---
From: David Tildesley [mailto:davo...@yahoo.co.nz]
Sent: Wednesday, December 31, 2014 4:36 PM
To: dev@isis.apache.org; us...@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddl
nterpretation to
Entities and ViewModels.
Or am I overlooking something? [I am new to Isis]
(fyi - there is a name clash with Model in Spring-MVC)
Jeremy D. Branham
Tel: **DOTNET
From: Jeroen van der Wal [mailto:jer...@stromboli.it]
Sent: Wednesday, December 31, 2014 7:37 AM
To: dev; users
Subject
Hi Vladimir
That's just the point I was making - using the term Entity to cover both
DDD.Entity archetype and DDD.ValueObject archetype is in fact a violation of
the DDD metamodel standard. Read page 89 of Eric's book.
I would have the same objection if ISIS chose to use Coad's colour modelling
ET
From: Jeroen van der Wal [mailto:jer...@stromboli.it]
Sent: Wednesday, December 31, 2014 7:37 AM
To: dev; users
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
I like this discussion because it's defining where Apache Isis is right now.
Personally I thin
Wal [mailto:jer...@stromboli.it]
Sent: Wednesday, December 31, 2014 7:37 AM
To: dev; users
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
I like this discussion because it's defining where Apache Isis is right now.
Personally I think Isis has grown far beyon
I like this discussion because it's defining where Apache Isis is right
now. Personally I think Isis has grown far beyond the concepts of DDD so
sticking to it's grammar would limit ourselves.
In the applications I'm developing things aren't black or white: we have
view models that represent docum
Hi to all.
I'm thinking about it but still convinced of option 1 ...
In my opinion, annotations are going to be "our main API". So they must be
thought from the user's perspective, more than from the implementation's
perspective.
In that way, aligning with DDD concepts (that are the most wide
I would vote for most well described DDD terms (described in Evans book) - this
would help users to adopt/understand ISIS framework easier and have a kind of
reference documentation. Term 'Object' is too general, and "Business Object
modelling antipatterns" are also very wide spreaded, e.g. by p
I can't help but think "DomainObject" is a far better representation of the
(Business) Problem Domain concept than "DomainEntity".
DDD for some reason known only to Eric Evans made a fetish of the term "Domain
Entity" as a type of "Domain Object". It was defined in juxtaposition to a
contrived
Hi Dan,
Perhaps a prefix that is layer agnostic for those annotations?
Regards,David.
On Wednesday, 31 December 2014 7:42 PM, Dan Haywood
wrote:
On 30 December 2014 at 23:44, David Tildesley wrote:
> +1 for the counter proposal (although I would suggest cloning/deriving
> "@Domai
On 30 December 2014 at 23:44, David Tildesley 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 r
Hi David, Ahmed...
Thanks for your votes.
So, this is interesting, the voting is now:
+3 for option 1
+4 for option 3.
This thread has been conducted on the dev list, not the users list. I'm
going to start a new thread over on users@isis.a.o to see if there are any
other opinions.
Cheers
Dan
Hi Devs,
I'm not a contributor but I think option 3 would be a mistake - it will
contribute to poor separation of concerns through obfuscation. Option 1 is the
best choice of the three presented.
Regards,David.
On Tuesday, 30 December 2014 4:13 AM, Dan Haywood
wrote:
OK, so it com
+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 Tuesday, 30 December 2014 3:07 AM, Dan Haywood
wrote:
On 29 December 2014 at 13:23, GESCONS
I would also vote for option 1
Netural GmbH - Digital Media in Excellence.
Ahmed Ragab, M.Sc. | Software Engineer
Peter-Behrens-Platz 2, 4020 Linz, Austria
Neustiftgasse 32-34, 1070 Wien, Austria
T +43 (0)732 790903-38, F +43 (0)732 79
This is basically Oscar's preference too, and I can see some merit in it.
And if one thinks of @DomainObject as being part of the domain layer only,
then it probably should also be renamed to @DomainEntity.
But the other thing to consider is that for each of these annotations we
also have a corre
Hi Dan,
>From your input, I assume a separate @ViewModel annotation is more consistent
>due to the fact that the view model is in the application layer where as
>@DomainObject is used with entities in the data/domain layer.
This will also help isolating specifics of both layers in upcoming
Hi Ahmed,
Thanks for the input.
On 30 December 2014 at 10:44, Ahmed Ragab wrote:
> I guess replacing persistence=JDO with persistence=INTERNAL|MANAGED|ISIS
> makes more sense with EXTERNAL and VIEW_MODEL since JDO is not the
> persistence scheme.
>
>
I do quite like all these names, and they
I guess replacing persistence=JDO with persistence=INTERNAL|MANAGED|ISIS makes
more sense with EXTERNAL and VIEW_MODEL since JDO is not the persistence scheme.
I don't know what persistence=VIEW_MODEL means but looks from the thread
comments that it makes sense. However I am still not sure if i
I guess the primary considerations are:
- grokkability for new-comers
- aesthetics
- alignment with DDD terminology.
Anyway, thanks for the vote.
On 30 December 2014 at 10:01, Kevin Meyer wrote:
> I've been on holiday and only now catching up...
>
> I vote for 3, but don't have insight to cho
I've been on holiday and only now catching up...
I vote for 3, but don't have insight to choose between 1 and 2 thereafter.
On 29 December 2014 16:11:24 CET, Dan Haywood
wrote:
>OK, so it comes down to either:
>
>
>*option 1:*
>
>*@DomainEntity(persistence=JDO|EXTERNAL)*
>*@ViewModel*
>
>with
ok, and I'm going to vote for (3) also.
@DomainObject(persistence=JDO | EXTERNAL | VIEW_MODEL)
with
@DomainObjectLayout
This is the first preference for Jeroen, Martin and Dan, and Oscar's second
preference.
~~~
In an earlier message there was a slightly different version of this:
@DomainOb
On Mon, Dec 29, 2014 at 5:11 PM, Dan Haywood
wrote:
> OK, so it comes down to either:
>
>
> *option 1:*
>
> *@DomainEntity(persistence=JDO|EXTERNAL)*
> *@ViewModel*
>
> with
>
> *@DomainEntityLayout*
> *@ViewModelLayout*
>
>
> where:
> * is symmetrical
> * some attributes of @DomainEntity don't a
On 29 December 2014 at 15:31, GESCONSULTOR - Óscar Bou <
o@gesconsultor.com> wrote:
> Just for clarification:
>
> The fact that:
> * some attributes of @DomainEntity don't apply if persistence=EXTERNAL
>
> It’s just a matter of current implementation, isn’t it?
> As auditing is implemented by
I would prefer to better align with DDD to gain support and be as clearer and
symmetric as possible.
So my order would be 1, 3, 2.
> El 29/12/2014, a las 16:30, Jeroen van der Wal escribió:
>
> My order of preference: 3, 1, 2
>
> On Mon, Dec 29, 2014 at 4:11 PM, Dan Haywood
> wrote:
>
>
Just for clarification:
The fact that:
* some attributes of @DomainEntity don't apply if persistence=EXTERNAL
It’s just a matter of current implementation, isn’t it?
As auditing is implemented by the persistence mechanism, when it’s external it
should be the responsibility of the developer to al
My order of preference: 3, 1, 2
On Mon, Dec 29, 2014 at 4:11 PM, Dan Haywood
wrote:
> OK, so it comes down to either:
>
>
> *option 1:*
>
> *@DomainEntity(persistence=JDO|EXTERNAL)*
> *@ViewModel*
>
> with
>
> *@DomainEntityLayout*
> *@ViewModelLayout*
>
>
> where:
> * is symmetrical
> * some at
OK, so it comes down to either:
*option 1:*
*@DomainEntity(persistence=JDO|EXTERNAL)*
*@ViewModel*
with
*@DomainEntityLayout*
*@ViewModelLayout*
where:
* is symmetrical
* some attributes of @DomainEntity don't apply if persistence=EXTERNAL
* the two layouts are basically identical to each ot
>
> Um, but they *are* part of the Isis metamodel, because we want them to be
> rendered in the UI. It's just that they aren't part of (what I suppose
> one might call) the persistence model.
>
> Any other suggestions if neither "traversable" nor "notPersisted" appeal?
>
No idea ... As per
>
>>
>> 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.
I agree with J
2014-12-29 14:51 GMT+00:00 GESCONSULTOR - Óscar Bou
:
>
> *** @Property ***
>
> - I would propose to rename "notPersisted" to "transient".
>
> So maybe "traversable" might be a better name (default = true)
>
> From the uses you provide, seems that uses like:
>
> - whether a changed property shou
> El 29/12/2014, a las 15:26, Dan Haywood
> escribió:
>
> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
> o@gesconsultor.com> wrote:
>
>>
>>
>> *** @Property ***
>>
>> - I would propose to rename "notPersisted" to "transient".
>>
>
> So maybe "traversable" might be a bette
On 29 December 2014 at 14:27, Jeroen van der Wal
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
I prefer the symmetrical approach: replace @ViewModel with
@DomainEntity(persistence=NEVER)?
Cheers,
Jeroen
PS Dan: do you still have that Google apps sheet with all annotations
floating around?
On Mon, Dec 29, 2014 at 3:05 PM, Dan Haywood
wrote:
> On 29 December 2014 at 13:23, GESCONSULTOR
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
o@gesconsultor.com> wrote:
>
>
> *** @Property ***
>
> - I would propose to rename "notPersisted" to "transient".
>
I'm slowly trying to eradicate the notion of "transient" objects from the
framework... they are a left over from the ol
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
On Mon, Dec 29, 2014 at 2:31 PM, Dan Haywood
wrote:
> On 29 December 2014 at 13:18, Jeroen van der Wal
> wrote:
>
> > Looks good to me too! Some comments:
> >
> > regexPatternReplacement:
> > Is this the input placeholder? In that case I would choose to add a
> > "placeholder" attribute on @Prop
On 29 December 2014 at 13:18, Jeroen van der Wal
wrote:
> Looks good to me too! Some comments:
>
> regexPatternReplacement:
> Is this the input placeholder? In that case I would choose to add a
> "placeholder" attribute on @PropertyLayout and @ParameterLayout [1]
>
>
No, it's to provide a user-f
Ok.
So let's raise some questions/doubts :)
*** @DomainObject ***
Is a ViewModel a DomainObject at all ?
I would consider them as a different kind, so the @ViewModel annotation
shouldn't be deleted.
Also, perhaps we can introduce Isis platform logic like not "saving/persisting"
view models,
Looks good to me too! Some comments:
regexPatternReplacement:
Is this the input placeholder? In that case I would choose to add a
"placeholder" attribute on @PropertyLayout and @ParameterLayout [1]
regexPatternFlags:
this is obsolete if you add "(?i)" to the pattern.
Cheers,
Jeroen
[1] http:
Hi,
Looks good to me!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Dec 29, 2014 at 12:36 PM, Dan Haywood
wrote:
> Hi folks,
>
> have done some further tidy up on the new annotations for domain semantics,
> ie @DomainObject, @Property, @Collection, @Acti
Hi folks,
have done some further tidy up on the new annotations for domain semantics,
ie @DomainObject, @Property, @Collection, @Action and @Parameter.
Nothing yet implemented in terms of facet factories, but think I have the
annotations themselves pretty much finalized [1].
Would appreciate a r
57 matches
Mail list logo
