[CAUSEWAY-1001] [WON'T FIX] For hard-coded methods such as title(), iconName(), and cssClass(), hidden(), disabled(), validate(), provide an alternative mechanism to specify such methods.

• Type: New Feature
• Status: Closed
• Priority: Minor
• Resolution: Won't Fix
• Affects Version/s: core-1.7.0
• Fix Version/s: 2.0.0-M5
• Component/s: Applib (programming model)
• Assignee: Daniel Keir Haywood
• Reporter: Daniel Keir Haywood
• Created: 06/Jan/15 20:42
• Updated: 17/Jan/21 18:54
• Resolved: 17/Jan/21 18:53

Description

The methods involved are:

• title()
• iconName()
• cssClass() (introduced in ISIS-1000)

and the (probably to be deprecated) callback methods:

• loaded()
• saving()/persisting()
• saved()/persisted()
• updating()
• updated()
• removing()/deleting()
• deleted()/deleted()

In all cases, if the method is annotated with @Action (ISIS-990) or with @Programmatic then it no facet should be installed (that is, action takes precedence).

Also, if there is a clashing action, then an annotation should indicate the method (analogous to junit's @Test annotation). Since these are all hook methods for Isis to call, I suggest the annotation is called @Hook, eg:

@Hook(HookType.TITLE)
String someOtherMethodActingLikeTitle() { ... }

@Hook(HookType.ICON_NAME)
String someMethodActingLikeIconName() {  .... }

@Hook(HookType.CSS_CLASS)
String someMethodActingLikeCssClass() { ... }

If an annotation doesn't appeal, we could instead define a special prefix, eg "__isis_xxx" (cf JUnit3's testXxx). For example:

String __isis_title()

{ ... }
String __isis_iconName() { ... }

String __isis_cssClass()

{ ... }