[jira] [Updated] (ISIS-970) Introduce new annotations to collect together all non-UI (layout) hints, and deprecate old annotations

[Dan Haywood (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ISIS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Haywood updated ISIS-970:
-
Description: 
specifically:
{code}
@DomainObject(
auditingPolicy = ENABLED|DISABLED|AS_CONFIGURED  // replaces @Audited
publishingPayloadFactory = SomePayloadFactory.class  // replaces 
@PublishedObject; possibly factor out PayloadFactory.Default so similar to 
interaction
autoCompleteRepository = SomeRepository.class  // instead of 
@AutoComplete(repository=...)
autoCompleteAction = autoComplete  // instead of 
@AutoComplete(action=...)
bounded  = true|false// instead of @Bounded.  takes 
precedence over autoComplete
editPolicy = ENABLED | DISABLED | AS_CONFIGURED // replaces @Immutable
objectType   = CUS  // instead of @ObjectType
viewModel= true|false// instead of @ViewModel, defaults 
to false
)
{code}
and
{code}
@Property(
interaction= ToDoItem.DueBy.class   // instead of @PropertyInteraction; 
PropertyInteractionEvent.Default.class for default
hidden  = Where.NO_WHERE etc // instead of @Hidden; 
ignore the When enum
disabled   = Where.OBJECT_FORMS etc.   // instead of @Disabled; ignore 
the When enum
disabledReason = ...// optional, 
representing @Disabled(reason=...)
maxLength= 20   // instead 
of @MaxLength; default of -1 indicates not specified
mustSatisfy  = {SomeSpecification.class}// instead of @MustSatisfy
notPersisted = true|false// instead of 
@NotPersisted; defaults to false
cardinality = DEFAULT|OPTIONAL|MANDATORY// instead of @Optional and 
@Mandatory.  Defaults to mandatory unless Column(allowsNull=true) is set.
regexPattern  = .+\@.+  // corresponds to 
@RegEx(validation=...)
regexPatternReplacement = email address  // corresponds to 
@RegEx(format=...)
regexPatternFlags = 1// superset of @RegEx(caseSensitive=...)
)
{code}
and
{code}
@Collection(
interaction =  ToDoItem.Dependencies.class   // instead of 
@CollectionInteraction; CollectionInteractionEvent.Default.class for default
hidden  = Where.NO_WHERE etc // instead of @Hidden; 
ignore the When enum
disabled   = Where.OBJECT_FORMS etc.   // instead of @Disabled; ignore 
the When enum
disabledReason = ...// optional, 
representing @Disabled(reason=...)
typeOf== OrderLine.class  // instead of 
@TypeOf
)
{code}
and
{code}
@Action(
interaction= ToDoItem.Completed.class  // instead of 
@ActionInteraction; ActionInteractionEvent.Default.class for default
hidden  = Where.NO_WHERE etc // instead of @Hidden; 
ignore the When enum
disabled   = Where.OBJECT_FORMS etc.   // instead of @Disabled; ignore 
the When enum
disabledReason = ...// optional, 
representing @Disabled(reason=...)
semantics  = Semantics.SAFE etc.   // instead of 
@ActionSemantics
appliesToPolicy  = AppliesTo.COLLECTION// or BULK_AND_REGULAR
commandPolicy   = ENABLED|DISABLED|AS_CONFIGURED// instead of @Command
commandPersistence = Persistence.PERSISTED // instead of 
@Command(persistence=...)
commandExecuteIn   = ExecuteIn.FOREGROUND  // instead of 
@Command(executeIn=...)
publishingPayloadFactory = SomePayloadFactory.class  // instead of 
@PublishedAction; probably factor out PayloadFactory.Default so similar to 
interaction
)
{code}
and
{code}
@Parameter(
minLength   = 3  // instead 
of @MinLength
mustSatisfy = {SomeSpecification.class}// instead of @MustSatisfy
cardinality = DEFAULT|OPTIONAL|MANDATORY// instead of @Optional
regexPattern  = .+\@.+  // corresponds to 
@RegEx(validation=...)
regexPatternReplacement = email address  // corresponds to 
@RegEx(format=...)
regexPatternFlags = 1// superset of @RegEx(caseSensitive=...)
)
{code}

for ISIS-964:
{code}
@DomainObjectLayout {
bookmarkable = BookmarkPolicy.ROOT   // or CHILD
}
{code}



This would result in the full complement of Isis annotations being:
- @DomainService  and @DomainServiceLayout
- @DomainObject  and @DomainObjectLayout
- @Property   and @PropertyLayout
- @Collection and @CollectionLayout
- @Action and @ActionLayout
- @Parameter and @ParameterLayout

Also two further additional UI hints:
- @Title
- @MemberGroupLayout

All the above @XxxLayout annotations can instead be specified using a 
.layout.json file.

The following 3rd-party annotations also supported:
- 

[jira] [Updated] (ISIS-970) Introduce new annotations to collect together all non-UI (layout) hints, and deprecate old annotations

[Dan Haywood (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ISIS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Haywood updated ISIS-970:
-
Description: 
specifically:
{code}
@DomainObject(
auditingPolicy = ENABLED|DISABLED|AS_CONFIGURED // instead of @Audited
publishingPayloadFactory = SomePayloadFactory.class // instead of 
@PublishedObject
autoCompleteRepository = SomeRepository.class   // instead of 
@AutoComplete(repository=...)
autoCompleteAction = autoComplete // instead of 
@AutoComplete(action=...)
bounded = true|false// instead of @Bounded. 
 takes precedence over autoComplete
editPolicy = ENABLED | DISABLED | AS_CONFIGURED // instead of @Immutable
objectType = CUS  // instead of 
@ObjectType
viewModel = true|false  // instead of 
@ViewModel, defaults to false
)
{code}
and
{code}
@Property(
interaction = ToDoItem.DueBy.class// instead of @PropertyInteraction
hidden = Where.NOWHERE etc// instead of @Hidden(where=...); 
ignore the When enum
disabled = Where.OBJECT_FORMS etc.// instead of 
@Disabled(where=...); ignore the When enum
disabledReason = ...// instead of 
@Disabled(reason=...)
maxLength = 20// instead of @MaxLength; default 
of -1 indicates not specified
mustSatisfy  = {SomeSpecification.class}  // instead of @MustSatisfy
notPersisted = true|false // instead of @NotPersisted; 
defaults to false
cardinality = DEFAULT|OPTIONAL|MANDATORY  // instead of @Optional and 
@Mandatory.  
regexPattern  = .+\@.+  // instead of 
@RegEx(validation=...)
regexPatternReplacement = email address // instead of @RegEx(format=...)
regexPatternFlags = 1 // superset of 
@RegEx(caseSensitive=...)
)
{code}
where cardinality defaults to mandatory unless Column(allowsNull=true) is set.

and
{code}
@Collection(
interaction = ToDoItem.Dependencies.class // instead of 
@CollectionInteraction
hidden = Where.NOWHERE etc// instead of @Hidden(where=...); 
ignore the When enum
disabled = Where.OBJECT_FORMS etc.// instead of 
@Disabled(where=...); ignore the When enum
disabledReason = ...// instead of 
@Disabled(reason=...)
typeOf = OrderLine.class  // instead of @TypeOf
)
{code}
and
{code}
@Action(
interaction = ToDoItem.Completed.class   // instead of 
@ActionInteraction
hidden = Where.NOWHERE etc   // instead of 
@Hidden(where=...); ignore the When enum
disabled = Where.OBJECT_FORMS etc.   // instead of 
@Disabled(where=...); ignore the When enum
disabledReason = ...   // instead of 
@Disabled(reason=...)
semantics = Semantics.SAFE etc.  // instead of 
@ActionSemantics
appliesToPolicy = AppliesTo.COLLECTION   // instead of @Bulk 
and @Bulk(appliesTo=...)
commandPolicy = ENABLED|DISABLED|AS_CONFIGURED   // instead of @Command
commandPersistence = Persistence.PERSISTED   // instead of 
@Command(persistence=...)
commandExecuteIn = ExecuteIn.FOREGROUND  // instead of 
@Command(executeIn=...)
publishingPayloadFactory = SomePayloadFactory.class  // instead of 
@PublishedAction
)
{code}
and
{code}
@Parameter(
minLength   = 3   // instead of @MinLength
mustSatisfy = {SomeSpecification.class}   // instead of @MustSatisfy
cardinality = DEFAULT|OPTIONAL|MANDATORY  // instead of @Optional and 
@Mandatory.  
regexPattern  = .+\@.+  // instead of 
@RegEx(validation=...)
regexPatternReplacement = email address // instead of 
@RegEx(format=...)
regexPatternFlags = 1 // superset of 
@RegEx(caseSensitive=...)
)
{code}

for ISIS-964:
{code}
@DomainObjectLayout {
bookmarkable = BookmarkPolicy.ROOT   // or CHILD
}
{code}



This would result in the full complement of Isis annotations being:
- @DomainService  and @DomainServiceLayout
- @DomainObject  and @DomainObjectLayout
- @Property   and @PropertyLayout
- @Collection and @CollectionLayout
- @Action and @ActionLayout
- @Parameter and @ParameterLayout

Also two further additional UI hints:
- @Title
- @MemberGroupLayout

All the above @XxxLayout annotations can instead be specified using a 
.layout.json file.

The following 3rd-party annotations also supported:
- @javax.validation.constraints.Digits
- @javax.enterprise.context.RequestScoped
- @javax.jdo.annotations.*

~~~
Need to decide what to do with remaining annotations (mostly pertaining to 
value types and other DDD ideas); remove or keep?  They are:
- @Value
- @Defaulted
- @Encodeable
- 

[jira] [Updated] (ISIS-970) Introduce new annotations to collect together all non-UI (layout) hints, and deprecate old annotations

[Dan Haywood (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ISIS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Haywood updated ISIS-970:
-
Description: 
specifically:
{code}
@DomainObject(
auditingPolicy = ENABLED|DISABLED|AS_CONFIGURED // instead of @Audited
publishingPayloadFactory = SomePayloadFactory.class // instead of 
@PublishedObject
autoCompleteRepository = SomeRepository.class   // instead of 
@AutoComplete(repository=...)
autoCompleteAction = autoComplete // instead of 
@AutoComplete(action=...)
bounded = true|false// instead of @Bounded. 
 takes precedence over autoComplete
editPolicy = ENABLED | DISABLED | AS_CONFIGURED // instead of @Immutable
objectType = CUS  // instead of 
@ObjectType
viewModel = true|false  // instead of 
@ViewModel, defaults to false
)
{code}
and
{code}
@Property(
interaction = ToDoItem.DueBy.class// instead of @PropertyInteraction
hidden = Where.NOWHERE etc// instead of @Hidden(where=...); 
ignore the When enum
disabled = Where.OBJECT_FORMS etc.// instead of 
@Disabled(where=...); ignore the When enum
disabledReason = ...// instead of 
@Disabled(reason=...)
maxLength = 20// instead of @MaxLength; default 
of -1 indicates not specified
mustSatisfy  = {SomeSpecification.class}  // instead of @MustSatisfy
notPersisted = true|false // instead of @NotPersisted; 
defaults to false
cardinality = DEFAULT|OPTIONAL|MANDATORY  // instead of @Optional and 
@Mandatory.  
regexPattern  = .+\@.+  // instead of 
@RegEx(validation=...)
regexPatternReplacement = email address // instead of @RegEx(format=...)
regexPatternFlags = 1 // superset of 
@RegEx(caseSensitive=...)
)
{code}
where cardinality defaults to mandatory unless Column(allowsNull=true) is set.

and
{code}
@Collection(
interaction = ToDoItem.Dependencies.class // instead of 
@CollectionInteraction
hidden = Where.NOWHERE etc// instead of @Hidden(where=...); 
ignore the When enum
disabled = Where.OBJECT_FORMS etc.// instead of 
@Disabled(where=...); ignore the When enum
disabledReason = ...// instead of 
@Disabled(reason=...)
typeOf = OrderLine.class  // instead of @TypeOf
)
{code}
and
{code}
@Action(
interaction = ToDoItem.Completed.class   // instead of 
@ActionInteraction
hidden = Where.NOWHERE etc   // instead of 
@Hidden(where=...); ignore the When enum
disabled = Where.OBJECT_FORMS etc.   // instead of 
@Disabled(where=...); ignore the When enum
disabledReason = ...   // instead of 
@Disabled(reason=...)
semantics = Semantics.SAFE etc.  // instead of 
@ActionSemantics
appliesToPolicy = AppliesTo.COLLECTION   // instead of @Bulk 
and @Bulk(appliesTo=...)
commandPolicy = ENABLED|DISABLED|AS_CONFIGURED   // instead of @Command
commandPersistence = Persistence.PERSISTED   // instead of 
@Command(persistence=...)
commandExecuteIn = ExecuteIn.FOREGROUND  // instead of 
@Command(executeIn=...)
publishingPayloadFactory = SomePayloadFactory.class  // instead of 
@PublishedAction
)
{code}
and
{code}
@Parameter(
minLength   = 3   // instead of @MinLength
mustSatisfy = {SomeSpecification.class}   // instead of @MustSatisfy
cardinality = DEFAULT|OPTIONAL|MANDATORY  // instead of @Optional and 
@Mandatory.  
regexPattern  = .+\@.+  // instead of 
@RegEx(validation=...)
regexPatternReplacement = email address // instead of 
@RegEx(format=...)
regexPatternFlags = 1 // superset of 
@RegEx(caseSensitive=...)
)
{code}

for ISIS-964:
{code}
@DomainObjectLayout {
bookmarkable = BookmarkPolicy.ROOT   // or CHILD
}
{code}



This would result in the fully supported non-deprecated Isis annotations 
reducing down to just 14.  The first 12 are:
- @DomainService  and @DomainServiceLayout
- @DomainObject  and @DomainObjectLayout
- @Property   and @PropertyLayout
- @Collection and @CollectionLayout
- @Action and @ActionLayout
- @Parameter and @ParameterLayout

with two further additional UI hints:
- @Title
- @MemberGroupLayout

All the above @XxxLayout annotations can instead be specified using a 
.layout.json file.

The following 3rd-party annotations also supported:
- @javax.validation.constraints.Digits
- @javax.enterprise.context.RequestScoped
- @javax.jdo.annotations.*

~~~
There are still a number of partially supported annotations, mostly pertaining 
to value types and other DDD ideas).  Need to 

[jira] [Created] (ISIS-988) Upgrade to log4j 2

[Vladimir Nisevic (JIRA)]

Vladimir Nisevic created ISIS-988:
-

 Summary: Upgrade to log4j 2 
 Key: ISIS-988
 URL: https://issues.apache.org/jira/browse/ISIS-988
 Project: Isis
  Issue Type: Question
  Components: Core
Reporter: Vladimir Nisevic
Assignee: Dan Haywood
Priority: Minor


We are using Isis in combination with Elasticsearch ELK Stack 
(http://www.elasticsearch.org/overview/)  where we send specific log events 
thru logging framework. Therefore it would be useful if we use log4j 2 features 
like AsyncAppender, see e.g. http://www.infoq.com/news/2014/07/apache-log4j2 

Regs
Vladimir



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ISIS-970) Introduce new annotations to collect together all non-UI (layout) hints, and deprecate old annotations

[Dan Haywood (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ISIS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Haywood updated ISIS-970:
-
Description: 
specifically:
{code}
@DomainObject(
auditing = ENABLED etc. (AuditingPolicy)// instead of @Audited
publishing = ENABLED etc. (PublishingPolicy)// instead of 
@PublishedObject
publishingPayloadFactory = SomePayloadFactory.class // instead of 
@PublishedObject(payloadFactory=...)
autoCompleteRepository = SomeRepository.class   // instead of 
@AutoComplete(repository=...)
autoCompleteAction = autoComplete // instead of 
@AutoComplete(action=...)
bounded = true|false// instead of @Bounded. 
 takes precedence over autoComplete
editing = ENABLED etc (EditingPolicy)   // instead of @Immutable
editingDisabledReason = ...   // instead of Always 
disabled message inferred from @Immutable
objectType = CUS  // instead of 
@ObjectType
viewModel = true|false  // instead of 
@ViewModel, defaults to false
)
{code}
and
{code}
@Property(
interaction = ToDoItem.DueBy.class// instead of @PropertyInteraction
hidden = Where.NOWHERE etc// instead of @Hidden(where=...); 
ignore the When enum
editing = ENABLED etc (EditingPolicy) // instead of @Disabled; ignore 
Where and When enums
editingDisabledReason = ... // instead of 
@Disabled(reason=...)
maxLength = 20// instead of @MaxLength; default 
of -1 indicates not specified
mustSatisfy  = {SomeSpecification.class}  // instead of @MustSatisfy
notPersisted = true|false // instead of @NotPersisted; 
defaults to false
cardinality = DEFAULT|OPTIONAL|MANDATORY  // instead of @Optional and 
@Mandatory.  
regexPattern  = .+\@.+  // instead of 
@RegEx(validation=...)
regexPatternReplacement = email address // instead of @RegEx(format=...)
regexPatternFlags = 1 // superset of 
@RegEx(caseSensitive=...)
)
{code}
where cardinality defaults to mandatory unless Column(allowsNull=true) is set.

and
{code}
@Collection(
interaction = ToDoItem.Dependencies.class // instead of 
@CollectionInteraction
hidden = Where.NOWHERE etc// instead of @Hidden(where=...); 
ignore the When enum
editing = ENABLED etc (EditingPolicy) // instead of @Disabled; ignore 
Where and When enums
editingDisabledReason = ... // instead of 
@Disabled(reason=...)
typeOf = OrderLine.class  // instead of @TypeOf
)
{code}
and
{code}
@Action(
interaction = ToDoItem.Completed.class  // instead of 
@ActionInteraction
hidden = Where.NOWHERE etc  // instead of 
@Hidden(where=...); ignore the When enum
semantics = Semantics.SAFE etc. // instead of 
@ActionSemantics
appliesToPolicy = AppliesTo.COLLECTION  // instead of @Bulk and 
@Bulk(appliesTo=...)
command = ENABLED|DISABLED|AS_CONFIGURED// instead of @Command
commandPersistence = Persistence.PERSISTED  // instead of 
@Command(persistence=...)
commandExecuteIn = ExecuteIn.FOREGROUND // instead of 
@Command(executeIn=...)
publishing = ENABLED etc. (PublishingPolicy)// instead of 
@PublishedAction
publishingPayloadFactory = SomePayloadFactory.class // instead of 
@PublishedAction(payloadFactory=...)
)
{code}
nb: @Disabled is no longer provided for actions (use imperative disableXxx() 
method instead if required)
and
{code}
@Parameter(
minLength   = 3   // instead of @MinLength
mustSatisfy = {SomeSpecification.class}   // instead of @MustSatisfy
cardinality = DEFAULT|OPTIONAL|MANDATORY  // instead of @Optional and 
@Mandatory.  
regexPattern  = .+\@.+  // instead of 
@RegEx(validation=...)
regexPatternReplacement = email address // instead of 
@RegEx(format=...)
regexPatternFlags = 1 // superset of 
@RegEx(caseSensitive=...)
)
{code}

for ISIS-964:
{code}
@DomainObjectLayout {
bookmarking = NEVER (BookmarkingPolicy)  // instead of @BookmarkPolicy
}
{code}



This would result in the fully supported non-deprecated Isis annotations 
reducing down to just 14.  The first 12 are:
- @DomainService  and @DomainServiceLayout
- @DomainObject  and @DomainObjectLayout
- @Property   and @PropertyLayout
- @Collection and @CollectionLayout
- @Action and @ActionLayout
- @Parameter and @ParameterLayout

with two further additional UI hints:
- @Title
- @MemberGroupLayout

All the above @XxxLayout annotations can instead be specified using a 
.layout.json file.

The following 3rd-party annotations also supported:
- 

[jira] [Commented] (ISIS-988) Upgrade to log4j 2

[Martin Grigorov (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259994#comment-14259994
 ] 

Martin Grigorov commented on ISIS-988:
--

I believe there is a ticket about using SLF4J as a facade for the logging 
framework.

 Upgrade to log4j 2 
 ---

 Key: ISIS-988
 URL: https://issues.apache.org/jira/browse/ISIS-988
 Project: Isis
  Issue Type: Question
  Components: Core
Reporter: Vladimir Nisevic
Assignee: Dan Haywood
Priority: Minor

 We are using Isis in combination with Elasticsearch ELK Stack 
 (http://www.elasticsearch.org/overview/)  where we send specific log events 
 thru logging framework. Therefore it would be useful if we use log4j 2 
 features like AsyncAppender, see e.g. 
 http://www.infoq.com/news/2014/07/apache-log4j2 
 Regs
 Vladimir



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ISIS-988) Upgrade to log4j 2

[Dan Haywood (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14260018#comment-14260018
 ] 

Dan Haywood commented on ISIS-988:
--

That ticket was implemented, meaning that we are mostly decoupled from log4j.  
In particular, only the slf4j API is used for logging (except in some tests)

Where there is still a dependency is that Isis' currently hard-codes how it 
configures log4j, this being in the IsisLoggingConfigurer class in the 
isis-core-log4j module.  That class is simply new'd up when Isis is 
bootstrapped.

So, I think what this ticket really requires is for that hard-coded dependency 
to be broken, such that the underlying logging mechanism be configured 
according to the components on the classpath.  Perhaps using the JDK6 
ServiceLoader API could be used so that we could discover the 
IsisLoggingConfigurer on the fly.

With that change made, it ought to be possible, just using Maven exclusions 
tag, to bind slf4j to use log4j.

Do you want to experiment with decoupling IsisLoggingConfigurer?

 Upgrade to log4j 2 
 ---

 Key: ISIS-988
 URL: https://issues.apache.org/jira/browse/ISIS-988
 Project: Isis
  Issue Type: Question
  Components: Core
Reporter: Vladimir Nisevic
Assignee: Dan Haywood
Priority: Minor

 We are using Isis in combination with Elasticsearch ELK Stack 
 (http://www.elasticsearch.org/overview/)  where we send specific log events 
 thru logging framework. Therefore it would be useful if we use log4j 2 
 features like AsyncAppender, see e.g. 
 http://www.infoq.com/news/2014/07/apache-log4j2 
 Regs
 Vladimir



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

ISIS-970 ... (new annotations) please review if you get a chance...

[Dan Haywood]

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 review from anyone interested, save me reworking stuff

Cheers
Dan

[1] https://issues.apache.org/jira/browse/ISIS-970

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Martin Grigorov]

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 d...@haywood-associates.co.uk
wrote:

 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 review from anyone interested, save me reworking stuff

 Cheers
 Dan

 [1] https://issues.apache.org/jira/browse/ISIS-970

[jira] [Commented] (ISIS-988) Upgrade to log4j 2

[Vladimir Nisevic (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14260027#comment-14260027
 ] 

Vladimir Nisevic commented on ISIS-988:
---

Ok, I will try to do it.

 Upgrade to log4j 2 
 ---

 Key: ISIS-988
 URL: https://issues.apache.org/jira/browse/ISIS-988
 Project: Isis
  Issue Type: Question
  Components: Core
Reporter: Vladimir Nisevic
Assignee: Dan Haywood
Priority: Minor

 We are using Isis in combination with Elasticsearch ELK Stack 
 (http://www.elasticsearch.org/overview/)  where we send specific log events 
 thru logging framework. Therefore it would be useful if we use log4j 2 
 features like AsyncAppender, see e.g. 
 http://www.infoq.com/news/2014/07/apache-log4j2 
 Regs
 Vladimir



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ISIS-970) Introduce new annotations to collect together all non-UI (layout) hints, and deprecate old annotations

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14260079#comment-14260079
 ] 

ASF subversion and git services commented on ISIS-970:
--

Commit 93a81dba2f557201043121fb1347f7262e080782 in isis's branch 
refs/heads/ISIS-970 from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=93a81db ]

ISIS-970: further tidy up and refinements to the new annotations and enums.  
First-cut (untested) implementation of @DomainObject facet factory.


 Introduce new annotations to collect together all non-UI (layout) hints, and 
 deprecate old annotations
 --

 Key: ISIS-970
 URL: https://issues.apache.org/jira/browse/ISIS-970
 Project: Isis
  Issue Type: Improvement
  Components: Core
Affects Versions: core-1.7.0
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: core-1.8.0


 specifically:
 {code}
 @DomainObject(
 auditing = ENABLED etc. (AuditingPolicy)// instead of @Audited
 publishing = ENABLED etc. (PublishingPolicy)// instead of 
 @PublishedObject
 publishingPayloadFactory = SomePayloadFactory.class // instead of 
 @PublishedObject(payloadFactory=...)
 autoCompleteRepository = SomeRepository.class   // instead of 
 @AutoComplete(repository=...)
 autoCompleteAction = autoComplete // instead of 
 @AutoComplete(action=...)
 bounded = true|false// instead of 
 @Bounded.  takes precedence over autoComplete
 editing = ENABLED etc (EditingPolicy)   // instead of 
 @Immutable
 editingDisabledReason = ...   // instead of Always 
 disabled message inferred from @Immutable
 objectType = CUS  // instead of 
 @ObjectType
 viewModel = true|false  // instead of 
 @ViewModel, defaults to false
 )
 {code}
 and
 {code}
 @Property(
 interaction = ToDoItem.DueBy.class// instead of 
 @PropertyInteraction
 hidden = Where.NOWHERE etc// instead of 
 @Hidden(where=...); ignore the When enum
 editing = ENABLED etc (EditingPolicy) // instead of @Disabled; ignore 
 Where and When enums
 editingDisabledReason = ... // instead of 
 @Disabled(reason=...)
 maxLength = 20// instead of @MaxLength; 
 default of -1 indicates not specified
 mustSatisfy  = {SomeSpecification.class}  // instead of @MustSatisfy
 notPersisted = true|false // instead of @NotPersisted; 
 defaults to false
 cardinality = DEFAULT|OPTIONAL|MANDATORY  // instead of @Optional and 
 @Mandatory.  
 regexPattern  = .+\@.+  // instead of 
 @RegEx(validation=...)
 regexPatternReplacement = email address // instead of @RegEx(format=...)
 regexPatternFlags = 1 // superset of 
 @RegEx(caseSensitive=...)
 )
 {code}
 where cardinality defaults to mandatory unless Column(allowsNull=true) is 
 set.
 and
 {code}
 @Collection(
 interaction = ToDoItem.Dependencies.class // instead of 
 @CollectionInteraction
 hidden = Where.NOWHERE etc// instead of 
 @Hidden(where=...); ignore the When enum
 editing = ENABLED etc (EditingPolicy) // instead of @Disabled; ignore 
 Where and When enums
 editingDisabledReason = ... // instead of 
 @Disabled(reason=...)
 typeOf = OrderLine.class  // instead of @TypeOf
 )
 {code}
 and
 {code}
 @Action(
 interaction = ToDoItem.Completed.class  // instead of 
 @ActionInteraction
 hidden = Where.NOWHERE etc  // instead of 
 @Hidden(where=...); ignore the When enum
 semantics = Semantics.SAFE etc. // instead of 
 @ActionSemantics
 appliesToPolicy = AppliesTo.COLLECTION  // instead of @Bulk 
 and @Bulk(appliesTo=...)
 command = ENABLED|DISABLED|AS_CONFIGURED// instead of @Command
 commandPersistence = Persistence.PERSISTED  // instead of 
 @Command(persistence=...)
 commandExecuteIn = ExecuteIn.FOREGROUND // instead of 
 @Command(executeIn=...)
 publishing = ENABLED etc. (PublishingPolicy)// instead of 
 @PublishedAction
 publishingPayloadFactory = SomePayloadFactory.class // instead of 
 @PublishedAction(payloadFactory=...)
 )
 {code}
 nb: @Disabled is no longer provided for actions (use imperative disableXxx() 
 method instead if required)
 and
 {code}
 @Parameter(
 minLength   = 3   // instead of @MinLength
 mustSatisfy = {SomeSpecification.class}   // instead of @MustSatisfy
 cardinality = 

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Jeroen van der Wal]

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://www.w3schools.com/tags/att_input_placeholder.asp

On Mon, Dec 29, 2014 at 11:45 AM, Martin Grigorov mgrigo...@apache.org
wrote:

 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 
 d...@haywood-associates.co.uk
 wrote:

  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 review from anyone interested, save me reworking stuff
 
  Cheers
  Dan
 
  [1] https://issues.apache.org/jira/browse/ISIS-970
 

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[GESCONSULTOR - Óscar Bou]

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, etc. If that would be the case, the editing and 
editingDisabledReason at least might not have any sense. 


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


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


*** @Property  ***

- I would propose to rename notPersisted to transient.
- Also, not sure about the exact meaning of regexPatternFlags. Should it be 
an Enum?
- I misunderstood cardinality. I always associated it with a number. 
Perhaps a better name could be isMandatory with a TRUE | FALSE | DEFAULT 
enum associated to its value? Another alternative could be persisting and 
default values DEFAULT | OPTIONAL | MANDATORY. Or, in order to be more 
generic (for example, to use the same name on the @Parameter annotation, it 
could be something like required.


*** @Parameter  ***

- Same as @Property. I suggest to rename cardinality to required.



HTH,

Oscar




 El 29/12/2014, a las 11:45, Martin Grigorov mgrigo...@apache.org escribió:
 
 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 d...@haywood-associates.co.uk
 wrote:
 
 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 review from anyone interested, save me reworking stuff
 
 Cheers
 Dan
 
 [1] https://issues.apache.org/jira/browse/ISIS-970
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Dan Haywood]

On 29 December 2014 at 13:18, Jeroen van der Wal jer...@stromboli.it
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-friendly message in the validation message.

eg: rather than say the input didn't match '.+@.+'

the message can say the input isn't a valid email address


(This is Rob Matthew's original design for @RegEx.  Looking at the current
implementation I think it's slightly broken, but I think it's worth
resurrecting/fixing).




 regexPatternFlags:
 this is obsolete if you add (?i) to the pattern.


True, but the flags parameter to compile covers more than this, see:

http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#compile(java.lang.String,%20int)


Thx
Dan



 Cheers,

 Jeroen


 [1] http://www.w3schools.com/tags/att_input_placeholder.asp

 On Mon, Dec 29, 2014 at 11:45 AM, Martin Grigorov mgrigo...@apache.org
 wrote:

  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 
  d...@haywood-associates.co.uk
  wrote:
 
   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 review from anyone interested, save me reworking
 stuff
  
   Cheers
   Dan
  
   [1] https://issues.apache.org/jira/browse/ISIS-970
  
 

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Jeroen van der Wal]

On Mon, Dec 29, 2014 at 2:31 PM, Dan Haywood d...@haywood-associates.co.uk
wrote:

 On 29 December 2014 at 13:18, Jeroen van der Wal jer...@stromboli.it
 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-friendly message in the validation message.

 eg: rather than say the input didn't match '.+@.+'

 the message can say the input isn't a valid email address


 (This is Rob Matthew's original design for @RegEx.  Looking at the current
 implementation I think it's slightly broken, but I think it's worth
 resurrecting/fixing).




  regexPatternFlags:
  this is obsolete if you add (?i) to the pattern.
 
 
 True, but the flags parameter to compile covers more than this, see:


 http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#compile(java.lang.String,%20int)


I would rather use the more portable regex modifier flags but that's a
matter of taste I guess:
http://www.regular-expressions.info/modifiers.html


 Thx
 Dan



  Cheers,
 
  Jeroen
 
 
  [1] http://www.w3schools.com/tags/att_input_placeholder.asp
 
  On Mon, Dec 29, 2014 at 11:45 AM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   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 
   d...@haywood-associates.co.uk
   wrote:
  
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 review from anyone interested, save me reworking
  stuff
   
Cheers
Dan
   
[1] https://issues.apache.org/jira/browse/ISIS-970
   
  
 

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Dan Haywood]

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

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Dan Haywood]

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 old client/server
implementations, and I think that view models make them reduncant.

But notPersisted might not be the right name either.

The current @NotPersisted annotation (=NotPersistedFacet) is basically a
hint as to how Isis should process object graphs.  It's used to determine:
- whether a changed property should be audited (ignore those that are
NotPersisted)
- whether a property of a view model should be used as part of its memento
(for @ViewModel)
- to determine if a property should be part of an internal memento (not to
be confused with the MementoService) of an object's state (I think the
Wicket viewer does use this in one place)
- for the old persistence-by-reachability stuff (probably superfluous now
that we use JDO)
- how to remap aggregated objects if parent changed (not sure if that
functionality is used by JDO, probably not)

So maybe traversable might be a better name (default = true)



 - Also, not sure about the exact meaning of regexPatternFlags. Should it
 be an Enum?


per response to Jeroen, it's the flag to Pattern.compile.

http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#compile(java.lang.String,%20int)



 - I misunderstood cardinality. I always associated it with a number.
 Perhaps a better name could be isMandatory with a TRUE | FALSE |
 DEFAULT enum associated to its value? Another alternative could be
 persisting and default values DEFAULT | OPTIONAL | MANDATORY. Or, in
 order to be more generic (for example, to use the same name on the
 @Parameter annotation, it could be something like required.


I struggled with this... I think that Cardinality can be used in this
way, but I see that wikipedia has a disambiguation page for the term, so
it's likely to confuse others too.

Given that we've historically used @Optional, perhaps it should be called
optional = TRUE|FALSE|DEFAULT.   Also in JDO we write
@javax.jdo.Column(allowNulls=true) so I think it'd be better to see
@Property(optional=TRUE) rather than @Property(mandatory=FALSE).




 *** @Parameter  ***

 - Same as @Property. I suggest to rename cardinality to required.



same comment; change to @Parameter(optional=TRUE|FALSE).  Javadoc to say
that DEFAULT shouldn't be used (but is a synonym for FALSE).


Thx again
Dan





 HTH,

 Oscar

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Jeroen van der Wal]

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


 

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Dan Haywood]

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 

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[GESCONSULTOR - Óscar Bou]

 El 29/12/2014, a las 15:26, Dan Haywood d...@haywood-associates.co.uk 
 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 better name (default = true)
 

From the uses you provide, seems that uses like:

- whether a changed property should be audited (ignore those that are
NotPersisted)
- whether a property of a view model should be used as part of its memento
(for @ViewModel)

are consequences of being transient or, at least, not part of the Isis 
Metamodel ??? 



 Given that we've historically used @Optional, perhaps it should be called
 optional = TRUE|FALSE|DEFAULT.   Also in JDO we write
 @javax.jdo.Column(allowNulls=true) so I think it'd be better to see
 @Property(optional=TRUE) rather than @Property(mandatory=FALSE).
 

I like a lot your @Property(optional=TRUE) proposal :)


 
 
 
 *** @Parameter  ***
 
 - Same as @Property. I suggest to rename cardinality to required.
 
 
 
 same comment; change to @Parameter(optional=TRUE|FALSE).  Javadoc to say
 that DEFAULT shouldn't be used (but is a synonym for FALSE).


Also here: @Parameter(optional=TRUE|FALSE)

Thanks!

 
 
 Thx again
 Dan
 
 
 
 
 
 HTH,
 
 Oscar
 
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Dan Haywood]

2014-12-29 14:51 GMT+00:00 GESCONSULTOR - Óscar Bou o@gesconsultor.com
:


 *** @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 should be audited (ignore those that are
 NotPersisted)
 - whether a property of a view model should be used as part of its memento
 (for @ViewModel)

 are consequences of being transient or, at least, not part of the Isis
 Metamodel ???



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.

NB: to fully ignore properties, we have @Programmatic (which I forgot to
mention earlier, but don't propose changing).

Any other suggestions if neither traversable nor notPersisted appeal?

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[GESCONSULTOR - Óscar Bou]

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

Currently there's nothing specific about Aggregate Roots on Apache Isis, at 
least on the most used modules, AFAK.


 
 * replace @DomainObject(viewModel=false)   with
 @DomainEntity(persistence=JDO)
   ... this would be the default

I like it :)


 * replace @DomainObject(viewModel=true)with
 @DomainEntity(persistence=EXTERNAL)

This one also!

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

I agree. It should be kept for those use cases.


 
 keep @DomainObjectLayout, because everything in it applies equally to both
 view models (either variety) and JDO entities.


M I would prefer to keep symmetry... I know it introduces some 
redundant checks on implementation but, from the user's perspective, is a 
clearer model ...

 
 
 I'll reply on your points on @Property and @Parameter separately.
 
 Thx
 Dan
 
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[GESCONSULTOR - Óscar Bou]

 
 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
 It's just that they aren't part of (what I suppose
 one might call) the persistence model.


Seems that the logical one would be notPersisted. But for you seems not 
compatible with previous @NotPersisted annotation ...

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Dan Haywood]

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 other


--- or ---

*option 2:*


*@DomainEntity(persistence=JDO|EXTERNAL)*
*@ViewModel*

with

*@DomainObjectLayout*


where:
* not symmetrical
* some attributes of @DomainEntity don't apply if persistence=EXTERNAL


--- or ---

*option 3:*

*@DomainObject(persistence=JDO|EXTERNAL|VIEW_MODEL)*

with

*@DomainObjectLayout*


where:
* is symmetrical
* some attributes of @DomainEntity don't apply if persistence=EXTERNAL or
VIEW_MODEL
* concept of view model is less visible



Cast your votes, please!

Dan



On 29 December 2014 at 15:02, GESCONSULTOR - Óscar Bou 
o@gesconsultor.com wrote:



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

 Currently there's nothing specific about Aggregate Roots on Apache Isis,
 at least on the most used modules, AFAK.



 * replace @DomainObject(viewModel=false)   with
 @DomainEntity(persistence=JDO)
   ... this would be the default


 I like it :)


 * replace @DomainObject(viewModel=true)with
 @DomainEntity(persistence=EXTERNAL)


 This one also!

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


 I agree. It should be kept for those use cases.



 keep @DomainObjectLayout, because everything in it applies equally to both
 view models (either variety) and JDO entities.



 M I would prefer to keep symmetry... I know it introduces some
 redundant checks on implementation but, from the user's perspective, is a
 clearer model ...



 I'll reply on your points on @Property and @Parameter separately.

 Thx
 Dan





 Óscar Bou Bou
 Responsable de Producto
 Auditor Jefe de Certificación ISO 27001 en BSI
 CISA, CRISC, APMG ISO 2, ITIL-F

902 900 231 / 620 267 520
http://www.twitter.com/oscarbou

http://es.linkedin.com/in/oscarbou

http://www.GesConsultor.com http://www.gesconsultor.com/



 Este mensaje y los ficheros anexos son confidenciales. Los mismos
 contienen información reservada que no puede ser difundida. Si usted ha
 recibido este correo por error, tenga la amabilidad de eliminarlo de su
 sistema y avisar al remitente mediante reenvío a su dirección electrónica;
 no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
 Su dirección de correo electrónico junto a sus datos personales constan en
 un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de
 mantener el contacto con Ud. Si quiere saber de qué información disponemos
 de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
 escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
 dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo -
 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia).
 Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
 adjuntos no contengan virus informáticos, y en caso que los tuvieran
 eliminarlos.

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Jeroen van der Wal]

My order of preference: 3, 1, 2

On Mon, Dec 29, 2014 at 4:11 PM, Dan Haywood d...@haywood-associates.co.uk
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 apply if persistence=EXTERNAL
 * the two layouts are basically identical to each other


 --- or ---

 *option 2:*


 *@DomainEntity(persistence=JDO|EXTERNAL)*
 *@ViewModel*

 with

 *@DomainObjectLayout*


 where:
 * not symmetrical
 * some attributes of @DomainEntity don't apply if persistence=EXTERNAL


 --- or ---

 *option 3:*

 *@DomainObject(persistence=JDO|EXTERNAL|VIEW_MODEL)*

 with

 *@DomainObjectLayout*


 where:
 * is symmetrical
 * some attributes of @DomainEntity don't apply if persistence=EXTERNAL or
 VIEW_MODEL
 * concept of view model is less visible



 Cast your votes, please!

 Dan



 On 29 December 2014 at 15:02, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:



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

 Currently there's nothing specific about Aggregate Roots on Apache Isis,
 at least on the most used modules, AFAK.



 * replace @DomainObject(viewModel=false)   with
 @DomainEntity(persistence=JDO)
   ... this would be the default


 I like it :)


 * replace @DomainObject(viewModel=true)with
 @DomainEntity(persistence=EXTERNAL)


 This one also!

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


 I agree. It should be kept for those use cases.



 keep @DomainObjectLayout, because everything in it applies equally to both
 view models (either variety) and JDO entities.



 M I would prefer to keep symmetry... I know it introduces some
 redundant checks on implementation but, from the user's perspective, is a
 clearer model ...



 I'll reply on your points on @Property and @Parameter separately.

 Thx
 Dan





 Óscar Bou Bou
 Responsable de Producto
 Auditor Jefe de Certificación ISO 27001 en BSI
 CISA, CRISC, APMG ISO 2, ITIL-F

902 900 231 / 620 267 520
http://www.twitter.com/oscarbou

http://es.linkedin.com/in/oscarbou

http://www.GesConsultor.com http://www.gesconsultor.com/



 Este mensaje y los ficheros anexos son confidenciales. Los mismos
 contienen información reservada que no puede ser difundida. Si usted ha
 recibido este correo por error, tenga la amabilidad de eliminarlo de su
 sistema y avisar al remitente mediante reenvío a su dirección electrónica;
 no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
 Su dirección de correo electrónico junto a sus datos personales constan
 en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la
 de mantener el contacto con Ud. Si quiere saber de qué información
 disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
 enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a
 la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana,
 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015
 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o
 sus archivos adjuntos no contengan virus informáticos, y en caso que los
 tuvieran eliminarlos.

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Dan Haywood]

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 the persistence mechanism, when it’s
 external it should be the responsibility of the developer to also provide
 support for it if desired.
 If external persistence support is extended (i.e., replaceable persistence
 mechanisms) “auditing” might be also part of it.

 Same can happen with other current limitations for externally persisted
 entities.


Yes, that's true.

In principle, auditing etc might be something that could be applied to any
entity, even one whose persistence is managed externally.

[jira] [Commented] (ISIS-970) Introduce new annotations to collect together all non-UI (layout) hints, and deprecate old annotations

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14260289#comment-14260289
 ] 

ASF subversion and git services commented on ISIS-970:
--

Commit 4e706794f3a6dcdef3764b079f0beac8ab056bb2 in isis's branch 
refs/heads/ISIS-970 from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=4e70679 ]

ISIS-970: facet factory for @Parameter annotation.


 Introduce new annotations to collect together all non-UI (layout) hints, and 
 deprecate old annotations
 --

 Key: ISIS-970
 URL: https://issues.apache.org/jira/browse/ISIS-970
 Project: Isis
  Issue Type: Improvement
  Components: Core
Affects Versions: core-1.7.0
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: core-1.8.0


 specifically:
 {code}
 @DomainObject(
 auditing = ENABLED etc. (AuditingPolicy)// instead of @Audited
 publishing = ENABLED etc. (PublishingPolicy)// instead of 
 @PublishedObject
 publishingPayloadFactory = SomePayloadFactory.class // instead of 
 @PublishedObject(payloadFactory=...)
 autoCompleteRepository = SomeRepository.class   // instead of 
 @AutoComplete(repository=...)
 autoCompleteAction = autoComplete // instead of 
 @AutoComplete(action=...)
 bounded = true|false// instead of 
 @Bounded.  takes precedence over autoComplete
 editing = ENABLED etc (EditingPolicy)   // instead of 
 @Immutable
 editingDisabledReason = ...   // instead of Always 
 disabled message inferred from @Immutable
 objectType = CUS  // instead of 
 @ObjectType
 viewModel = true|false  // instead of 
 @ViewModel, defaults to false
 )
 {code}
 and
 {code}
 @Property(
 interaction = ToDoItem.DueBy.class// instead of 
 @PropertyInteraction
 hidden = Where.NOWHERE etc// instead of 
 @Hidden(where=...); ignore the When enum
 editing = ENABLED etc (EditingPolicy) // instead of @Disabled; ignore 
 Where and When enums
 editingDisabledReason = ... // instead of 
 @Disabled(reason=...)
 maxLength = 20// instead of @MaxLength; 
 default of -1 indicates not specified
 mustSatisfy  = {SomeSpecification.class}  // instead of @MustSatisfy
 notPersisted = true|false // instead of @NotPersisted; 
 defaults to false
 cardinality = DEFAULT|OPTIONAL|MANDATORY  // instead of @Optional and 
 @Mandatory.  
 regexPattern  = .+\@.+  // instead of 
 @RegEx(validation=...)
 regexPatternReplacement = email address // instead of @RegEx(format=...)
 regexPatternFlags = 1 // superset of 
 @RegEx(caseSensitive=...)
 )
 {code}
 where cardinality defaults to mandatory unless Column(allowsNull=true) is 
 set.
 and
 {code}
 @Collection(
 interaction = ToDoItem.Dependencies.class // instead of 
 @CollectionInteraction
 hidden = Where.NOWHERE etc// instead of 
 @Hidden(where=...); ignore the When enum
 editing = ENABLED etc (EditingPolicy) // instead of @Disabled; ignore 
 Where and When enums
 editingDisabledReason = ... // instead of 
 @Disabled(reason=...)
 typeOf = OrderLine.class  // instead of @TypeOf
 )
 {code}
 and
 {code}
 @Action(
 interaction = ToDoItem.Completed.class  // instead of 
 @ActionInteraction
 hidden = Where.NOWHERE etc  // instead of 
 @Hidden(where=...); ignore the When enum
 semantics = Semantics.SAFE etc. // instead of 
 @ActionSemantics
 appliesToPolicy = AppliesTo.COLLECTION  // instead of @Bulk 
 and @Bulk(appliesTo=...)
 command = ENABLED|DISABLED|AS_CONFIGURED// instead of @Command
 commandPersistence = Persistence.PERSISTED  // instead of 
 @Command(persistence=...)
 commandExecuteIn = ExecuteIn.FOREGROUND // instead of 
 @Command(executeIn=...)
 publishing = ENABLED etc. (PublishingPolicy)// instead of 
 @PublishedAction
 publishingPayloadFactory = SomePayloadFactory.class // instead of 
 @PublishedAction(payloadFactory=...)
 )
 {code}
 nb: @Disabled is no longer provided for actions (use imperative disableXxx() 
 method instead if required)
 and
 {code}
 @Parameter(
 minLength   = 3   // instead of @MinLength
 mustSatisfy = {SomeSpecification.class}   // instead of @MustSatisfy
 cardinality = DEFAULT|OPTIONAL|MANDATORY  // instead of @Optional and 
 @Mandatory.  
 regexPattern  = 

[jira] [Commented] (ISIS-970) Introduce new annotations to collect together all non-UI (layout) hints, and deprecate old annotations

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14260298#comment-14260298
 ] 

ASF subversion and git services commented on ISIS-970:
--

Commit 06c8199a31bc04dc39d50f19a0e0118965ae3808 in isis's branch 
refs/heads/ISIS-970 from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=06c8199 ]

ISIS-970: started on the facet factories for @Collection and @Action.

Also renamed XxxFactory - XxxAnnotationFacetFactory for 
Xxx=DomainObject,Property,Parameter.


 Introduce new annotations to collect together all non-UI (layout) hints, and 
 deprecate old annotations
 --

 Key: ISIS-970
 URL: https://issues.apache.org/jira/browse/ISIS-970
 Project: Isis
  Issue Type: Improvement
  Components: Core
Affects Versions: core-1.7.0
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: core-1.8.0


 specifically:
 {code}
 @DomainObject(
 auditing = ENABLED etc. (AuditingPolicy)// instead of @Audited
 publishing = ENABLED etc. (PublishingPolicy)// instead of 
 @PublishedObject
 publishingPayloadFactory = SomePayloadFactory.class // instead of 
 @PublishedObject(payloadFactory=...)
 autoCompleteRepository = SomeRepository.class   // instead of 
 @AutoComplete(repository=...)
 autoCompleteAction = autoComplete // instead of 
 @AutoComplete(action=...)
 bounded = true|false// instead of 
 @Bounded.  takes precedence over autoComplete
 editing = ENABLED etc (EditingPolicy)   // instead of 
 @Immutable
 editingDisabledReason = ...   // instead of Always 
 disabled message inferred from @Immutable
 objectType = CUS  // instead of 
 @ObjectType
 viewModel = true|false  // instead of 
 @ViewModel, defaults to false
 )
 {code}
 and
 {code}
 @Property(
 interaction = ToDoItem.DueBy.class// instead of 
 @PropertyInteraction
 hidden = Where.NOWHERE etc// instead of 
 @Hidden(where=...); ignore the When enum
 editing = ENABLED etc (EditingPolicy) // instead of @Disabled; ignore 
 Where and When enums
 editingDisabledReason = ... // instead of 
 @Disabled(reason=...)
 maxLength = 20// instead of @MaxLength; 
 default of -1 indicates not specified
 mustSatisfy  = {SomeSpecification.class}  // instead of @MustSatisfy
 notPersisted = true|false // instead of @NotPersisted; 
 defaults to false
 cardinality = DEFAULT|OPTIONAL|MANDATORY  // instead of @Optional and 
 @Mandatory.  
 regexPattern  = .+\@.+  // instead of 
 @RegEx(validation=...)
 regexPatternReplacement = email address // instead of @RegEx(format=...)
 regexPatternFlags = 1 // superset of 
 @RegEx(caseSensitive=...)
 )
 {code}
 where cardinality defaults to mandatory unless Column(allowsNull=true) is 
 set.
 and
 {code}
 @Collection(
 interaction = ToDoItem.Dependencies.class // instead of 
 @CollectionInteraction
 hidden = Where.NOWHERE etc// instead of 
 @Hidden(where=...); ignore the When enum
 editing = ENABLED etc (EditingPolicy) // instead of @Disabled; ignore 
 Where and When enums
 editingDisabledReason = ... // instead of 
 @Disabled(reason=...)
 typeOf = OrderLine.class  // instead of @TypeOf
 )
 {code}
 and
 {code}
 @Action(
 interaction = ToDoItem.Completed.class  // instead of 
 @ActionInteraction
 hidden = Where.NOWHERE etc  // instead of 
 @Hidden(where=...); ignore the When enum
 semantics = Semantics.SAFE etc. // instead of 
 @ActionSemantics
 appliesToPolicy = AppliesTo.COLLECTION  // instead of @Bulk 
 and @Bulk(appliesTo=...)
 command = ENABLED|DISABLED|AS_CONFIGURED// instead of @Command
 commandPersistence = Persistence.PERSISTED  // instead of 
 @Command(persistence=...)
 commandExecuteIn = ExecuteIn.FOREGROUND // instead of 
 @Command(executeIn=...)
 publishing = ENABLED etc. (PublishingPolicy)// instead of 
 @PublishedAction
 publishingPayloadFactory = SomePayloadFactory.class // instead of 
 @PublishedAction(payloadFactory=...)
 )
 {code}
 nb: @Disabled is no longer provided for actions (use imperative disableXxx() 
 method instead if required)
 and
 {code}
 @Parameter(
 minLength   = 3   // instead of @MinLength
 mustSatisfy = {SomeSpecification.class}   // instead of @MustSatisfy
 

[jira] [Commented] (ISIS-987) Provide some sort of mechanism to allow users to self-register for an Isis application.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14260398#comment-14260398
 ] 

ASF subversion and git services commented on ISIS-987:
--

Commit 3bd8294d6410b4a02baa9384ba7193f8c12dcf0c in isis's branch 
refs/heads/ISIS-987 from [~mgrigorov]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=3bd8294 ]

ISIS-987 Provide some sort of mechanism to allow users to self-register for an 
Isis application.

Add register (email), verify, register user data flow.


 Provide some sort of mechanism to allow users to self-register for an Isis 
 application.
 ---

 Key: ISIS-987
 URL: https://issues.apache.org/jira/browse/ISIS-987
 Project: Isis
  Issue Type: New Feature
  Components: Core, Viewer: Wicket
Affects Versions: viewer-wicket-1.7.0, core-1.7.0
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: viewer-wicket-1.9.0, core-1.9.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ISIS-987) Provide some sort of mechanism to allow users to self-register for an Isis application.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14260401#comment-14260401
 ] 

ASF subversion and git services commented on ISIS-987:
--

Commit 065bc101be2bee2ee4f3f4ef93fd2be1867b1b93 in isis's branch 
refs/heads/ISIS-987 from [~mgrigorov]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=065bc10 ]

ISIS-987 Provide some sort of mechanism to allow users to self-register for an 
Isis application.

Add validator that checks whether there is a user with a given email.
Add TODO to PasswordReset logic.


 Provide some sort of mechanism to allow users to self-register for an Isis 
 application.
 ---

 Key: ISIS-987
 URL: https://issues.apache.org/jira/browse/ISIS-987
 Project: Isis
  Issue Type: New Feature
  Components: Core, Viewer: Wicket
Affects Versions: viewer-wicket-1.7.0, core-1.7.0
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: viewer-wicket-1.9.0, core-1.9.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[Martin Grigorov]

On Mon, Dec 29, 2014 at 5:11 PM, Dan Haywood d...@haywood-associates.co.uk
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 apply if persistence=EXTERNAL
 * the two layouts are basically identical to each other


 --- or ---

 *option 2:*


 *@DomainEntity(persistence=JDO|EXTERNAL)*
 *@ViewModel*

 with

 *@DomainObjectLayout*


 where:
 * not symmetrical
 * some attributes of @DomainEntity don't apply if persistence=EXTERNAL


 --- or ---

 *option 3:*

 *@DomainObject(persistence=JDO|EXTERNAL|VIEW_MODEL)*

 with

 *@DomainObjectLayout*


 where:
 * is symmetrical
 * some attributes of @DomainEntity don't apply if persistence=EXTERNAL or
 VIEW_MODEL
 * concept of view model is less visible



 Cast your votes, please!


I vote for 3)

In any case metamodel validation would be very useful!



 Dan



 On 29 December 2014 at 15:02, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:



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

 Currently there's nothing specific about Aggregate Roots on Apache Isis,
 at least on the most used modules, AFAK.



 * replace @DomainObject(viewModel=false)   with
 @DomainEntity(persistence=JDO)
   ... this would be the default


 I like it :)


 * replace @DomainObject(viewModel=true)with
 @DomainEntity(persistence=EXTERNAL)


 This one also!

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


 I agree. It should be kept for those use cases.



 keep @DomainObjectLayout, because everything in it applies equally to both
 view models (either variety) and JDO entities.



 M I would prefer to keep symmetry... I know it introduces some
 redundant checks on implementation but, from the user's perspective, is a
 clearer model ...



 I'll reply on your points on @Property and @Parameter separately.

 Thx
 Dan





 Óscar Bou Bou
 Responsable de Producto
 Auditor Jefe de Certificación ISO 27001 en BSI
 CISA, CRISC, APMG ISO 2, ITIL-F

902 900 231 / 620 267 520
http://www.twitter.com/oscarbou

http://es.linkedin.com/in/oscarbou

http://www.GesConsultor.com http://www.gesconsultor.com/



 Este mensaje y los ficheros anexos son confidenciales. Los mismos
 contienen información reservada que no puede ser difundida. Si usted ha
 recibido este correo por error, tenga la amabilidad de eliminarlo de su
 sistema y avisar al remitente mediante reenvío a su dirección electrónica;
 no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
 Su dirección de correo electrónico junto a sus datos personales constan
 en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la
 de mantener el contacto con Ud. Si quiere saber de qué información
 disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
 enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a
 la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana,
 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015
 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o
 sus archivos adjuntos no contengan virus informáticos, y en caso que los
 tuvieran eliminarlos.

[jira] [Commented] (ISIS-987) Provide some sort of mechanism to allow users to self-register for an Isis application.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14260879#comment-14260879
 ] 

ASF subversion and git services commented on ISIS-987:
--

Commit 790470c80a7baa02816d0cd76e5ddb772cd50958 in isis's branch 
refs/heads/ISIS-987 from [~mgrigorov]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=790470c ]

ISIS-987 Provide some sort of mechanism to allow users to self-register for an 
Isis application.

Password reset UI improvements.


 Provide some sort of mechanism to allow users to self-register for an Isis 
 application.
 ---

 Key: ISIS-987
 URL: https://issues.apache.org/jira/browse/ISIS-987
 Project: Isis
  Issue Type: New Feature
  Components: Core, Viewer: Wicket
Affects Versions: viewer-wicket-1.7.0, core-1.7.0
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: viewer-wicket-1.9.0, core-1.9.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)