Re: Any opinions on this proposal (ISIS-970) to reduce the number of Isis annotations?

2014-12-10 Thread Dan Haywood
On 10 December 2014 at 09:09, GESCONSULTOR - Óscar Bou 
o@gesconsultor.com wrote:

 First thoughts here ...


 It seems obvious that it would be clearer and also easier to learn (as you
 could easily discover all property, collection or action options easily
 simply by looking at the possible annotation fields.


Yes, that's my main motivation... grokkability/discoverability.





 So seems a great idea  ... :))


OK, thanks for the vote.





 I miss name as an equivalent to @Named.


Hmmm, it should be there, for all of the @XxxLayout annotations, eg

@DomainServiceLayout(named=...)
@PropertyLayout(named=...)

etc

It's in the XxxLayout annotations (rather than the domain annotations)
because it only impacts the UI.

Thx
Dan


Re: Any opinions on this proposal (ISIS-970) to reduce the number of Isis annotations?

2014-12-10 Thread Martin Grigorov
Hi,

The improvement is good ! Especially for newcomers.

What is the backward compatibility policy ?
I didn't have a chance to review the changes but I assume the old
annotations will be supported for 1.x, probably deprecated ?

On Wed, Dec 10, 2014 at 11:16 AM, Dan Haywood d...@haywood-associates.co.uk
wrote:

 On 10 December 2014 at 09:09, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:

  First thoughts here ...
 
 
  It seems obvious that it would be clearer and also easier to learn (as
 you
  could easily discover all property, collection or action options easily
  simply by looking at the possible annotation fields.
 

 Yes, that's my main motivation... grokkability/discoverability.




 
  So seems a great idea  ... :))
 

 OK, thanks for the vote.




 
  I miss name as an equivalent to @Named.
 
 
 Hmmm, it should be there, for all of the @XxxLayout annotations, eg

 @DomainServiceLayout(named=...)
 @PropertyLayout(named=...)

 etc

 It's in the XxxLayout annotations (rather than the domain annotations)
 because it only impacts the UI.

 Thx
 Dan



[jira] [Updated] (ISIS-972) Make it possible to set FontAwesome icons after the label for action links

2014-12-10 Thread Martin Grigorov (JIRA)

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

Martin Grigorov updated ISIS-972:
-
Attachment: fa-icon-after-label.png

 Make it possible to set FontAwesome icons after the label for action links
 --

 Key: ISIS-972
 URL: https://issues.apache.org/jira/browse/ISIS-972
 Project: Isis
  Issue Type: Improvement
  Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.8.0
Reporter: Martin Grigorov
Assignee: Dan Haywood
Priority: Minor
 Attachments: fa-icon-after-label.png


 By using org.apache.isis.applib.annotation.ActionLayout#cssClassFa() one can 
 set a custom FontAwesome icon for an action link.
 The small issue that I see in ToDo App is that the icon is used always as a 
 prefix for the link's label.
 Sometimes it may make more sense to use if as a suffix, e.g. for the Next 
 link in Priority section. See screenshot.



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


[jira] [Created] (ISIS-972) Make it possible to set FontAwesome icons after the label for action links

2014-12-10 Thread Martin Grigorov (JIRA)
Martin Grigorov created ISIS-972:


 Summary: Make it possible to set FontAwesome icons after the label 
for action links
 Key: ISIS-972
 URL: https://issues.apache.org/jira/browse/ISIS-972
 Project: Isis
  Issue Type: Improvement
  Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.8.0
Reporter: Martin Grigorov
Assignee: Dan Haywood
Priority: Minor
 Attachments: fa-icon-after-label.png

By using org.apache.isis.applib.annotation.ActionLayout#cssClassFa() one can 
set a custom FontAwesome icon for an action link.
The small issue that I see in ToDo App is that the icon is used always as a 
prefix for the link's label.
Sometimes it may make more sense to use if as a suffix, e.g. for the Next 
link in Priority section. See screenshot.



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

2014-12-10 Thread Jeroen van der Wal (JIRA)

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

Jeroen van der Wal commented on ISIS-970:
-

Good stuff, this will make it much easier for newcomers. Personally the 
remaining annotations could be removed for now and reinstated if they fit a 
purpose in Isis again. One little thing: the objectType on @DomainObject 
actually is the objectName.

 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(
 audited = true|false
 auditedDisabled = true|false // representing 
 @Audited(disabled=true)
 published= SomePayloadFactory.class  // probably factor out 
 PayloadFactory.Default so similar to interaction
 autoComplete = SomeRepository.class
 bookmarkable = BookmarkPolicy.ROOT   // or CHILD
 bounded  = true|false// do not combine with 
 autoComplete
 immutable= When.ALWAYS   // or perhaps true|false; 
 defaults to ?  perhaps true ?
 objectType   = CUS
 viewModel= true|false// defaults to false
 )
 {code}
 and
 {code}
 @Property(
 interaction= ToDoItem.DueBy.class   // or 
 PropertyInteractionEvent.Default.class for default
 disabled   = Where.OBJECT_FORMS etc.   // (ignore the When enum)
 disabledReason = ... // optional, representing 
 @Disabled(reason=...)
 maxLength= 20
 mustSatisfy  = {SomeSpecification.class}
 notPersisted = true|false  // defaults to false
 optional = true|false  // defaults to false (ie 
 mandatory)
 regex= abc.*def  // ignore the validation and 
 caseSensitive attributes
 )
 {code}
 and
 {code}
 @Collection(
 interaction=
 disabled   = Where.OBJECT_FORMS etc.   // (ignore the When enum)
 disabledReason = ... // optional, representing 
 @Disabled(reason=...)
 typeOf== OrderLine.class
 )
 {code}
 and
 {code}
 @Action(
 interaction= ToDoItem.Completed.class  // or 
 ActionInteractionEvent.Default.class for default
 disabled   = Where.OBJECT_FORMS etc.   // (ignore the When enum)
 disabledReason = ... // optional, representing 
 @Disabled(reason=...)
 semantics  = Of.SAFE   // or IDEMPOTENT, 
 NON_IDEMPOTENT  
 bulk   = AppliesTo.BULK_ONLY   // or BULK_AND_REGULAR
 command= true|false
 commandPersistence = Persistence.PERSISTED // representing 
 @Command(persistence=...)
 commandExecuteIn   = ExecuteIn.FOREGROUND  // representing 
 @Command(executeIn=...)
 commandDisabled= true|false// representing 
 @Command(disabled=true)
 published  = SomePayloadFactory.class  // probably factor out 
 PayloadFactory.Default so similar to interaction
 )
 {code}
 and
 {code}
 @Parameter(
 minLength   = 3
 mustSatisfy = {SomeSpecification.class}
 optional= true|false  // defaults to false (ie 
 mandatory)
 regex   = abc.*def  // ignore the validation and 
 caseSensitive attributes
 )
 {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
 - @EqualByContent
 - @Parseable
 - @Aggregated
 - @NotPersistable
 - @Facets



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


[jira] [Commented] (ISIS-972) Make it possible to set FontAwesome icons after the label for action links

2014-12-10 Thread Martin Grigorov (JIRA)

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

Martin Grigorov commented on ISIS-972:
--

If you like the idea then I may try to implement it myself.
I see two ways:
1) make org.apache.isis.applib.annotation.ActionLayout#cssClassFa() returning 
some specialized class that brings both the class name and position
2) add a new method to ActionLayout, e.g. cssClassFaPosition default LEFT.

 Make it possible to set FontAwesome icons after the label for action links
 --

 Key: ISIS-972
 URL: https://issues.apache.org/jira/browse/ISIS-972
 Project: Isis
  Issue Type: Improvement
  Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.8.0
Reporter: Martin Grigorov
Assignee: Dan Haywood
Priority: Minor
 Attachments: fa-icon-after-label.png


 By using org.apache.isis.applib.annotation.ActionLayout#cssClassFa() one can 
 set a custom FontAwesome icon for an action link.
 The small issue that I see in ToDo App is that the icon is used always as a 
 prefix for the link's label.
 Sometimes it may make more sense to use if as a suffix, e.g. for the Next 
 link in Priority section. See screenshot.



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