The different aspects of the Isis Script DSL are explained in the following sections.
To define a namespace for an Isis Script object the corresponding Java notion of packages and imports are supported. So the keywords package and import are used in the same way as in Java classes:
package org.vaulttec.types
import org.vaulttec.types.other.SomeSuperType
entity SomeType extends SomeSuperType {
}
To generate code which refers to the application's module type (e.g. the hierarchy of domain event types) a reference to the corresponding type is needed. This reference is defined with the keyword module:
package domainapp.dom.modules.simple
module domainapp.dom.SimpleAppModule
entity SimpleObject {
}
Persistent domain objects (entities) are defined with the keyword entity. They have a unique name and are preceeded by Isis or selected JDO annotations.
@... // Isis and JDO annotations
entity SomeType {
}
By using the keyword extends an entity can inherit from another entity:
entity SomeType extends SomeSuperType {
}
With the keyword inject an Isis service can be autowired (field injection) into an entity:
entity SomeType {
inject OtherTypeRepository others;
}
The keyword property is used to define a Java bean property (a field with corresponding getter and setter) for an entity:
entity SomeType {
@... // Isis and JDO annotations
property int someProperty
}
A property can have additional features (supporting methods), e.g. default values or validation rules:
entity SomeType {
property int someProperty {
default {
1
}
validate {
if (value < 0 && value > 10)
"Proposed value out of bounds"
else
null
}
}
}
}
These features are described in the following chapters.
For properties imperative rules for visibility, usability and validity can be defined. These business rules provide additional checking and behaviour to be performed when the user interacts with those object members.
The keyword hide defines a boolean expression for hiding the property:
property int someProperty {
hide {
isBlacklisted()
}
}
The keyword disable defines an expression for disabling (making read-only) the property. It returns a string with the reason for disabling or null if not disabled:
property int someProperty {
disable {
if (isBlacklisted())
"Cannot change for blacklisted entities")
else
null
}
}
The keyword validate defines an expression which validates a proposed value (parameter named value). It returns a string which is the reason the modification is vetoed or null if not vetoed:
property int someProperty {
validate {
if (value < 0 && value > 10)
"Proposed value out of bounds"
else
null
}
}
The keyword derived defines an expression which is used as getter of a non-persistent (derived) property. Derived properties have no instance variable and setter.
property int someProperty {
derived {
someCalculation()
}
}
For these properties only the business rule hide is allowed.
The keyword modify defines an expression to update a property with a given value (parameter name value):
property int someProperty {
modify {
doSomeStuff()
setSomeProperty(value)
doSomeOtherStuff()
}
}
Using this method allows business logic to be placed apart from the setter.
The keyword clear defines an expression to set a property to null:
property String someProperty {
clear {
doSomeStuff()
setSomeProperty(null)
doSomeOtherStuff()
}
}
Using this method allows business logic to be placed apart from the setter.
The keyword choices defines an expression which returns a collection of values for this property. These values are used for populating drop-down list boxes:
property int someProperty {
choices {
#[1, 2, 3]
}
}
The keyword complete defines an expression which returns a collection of values from a properties drop-down list box for a given search string (parameter name is search):
property int someProperty {
@MinLength(3)
complete {
switch search {
case 'min' : #[1, 2]
case 'max' : #[2, 3]
default : #[]
}
}
}
The optional annotation @MinLength specifies the minimum number of characters that must be entered before the auto-complete method is called.
The keyword default defines an expression which returns the initial argument value for this property:
property int someProperty {
default {
2
}
}
With the keyword event a custom domain event (subtype of PropertyDomainEvent) can be defined:
@Property(domainEvent = SomeEvent)
property int someProperty {
event SomeEvent
}
If the keyword module is present then the generated custom domain event type inherits from a subtype within the domain event type hierarchy instead of the corresponding Isis library type.
The keyword collection is used to define a collection property (with its type and initial value) for an entity:
entity SomeType {
@... // Isis and JDO annotations
collection Set<OtherType> someCollection = new TreeSet<>() {
}
}
A collection can have additional attributes (supporting methods), e.g. disable:
entity SomeType {
collection Set<OtherType> someCollection = new TreeSet<>() {
disable {
if (isBlacklisted())
"Cannot changed for blacklisted entities")
else
null
}
}
}
These features are described in the following chapters.
For collection imperative rules for visibility, usability and validity can be defined. These business rules provide additional checking and behaviour to be performed when the user interacts with those object collections.
The keyword hide defines a boolean expression for hiding the collection:
collection Set<OtherType> someCollection = new TreeSet<>() {
hide {
isBlacklisted()
}
}
The keyword disable defines an expression for disabling the collection.
It returns a string with the reason for disabling or null if not disabled:
collection Set<OtherType> someCollection = new TreeSet<>() {
disable {
if (isBlacklisted())
"Not allowed for blacklisted entities")
else
null
}
}
The keyword validate[AddTo|RemoveFrom] defines an expression which validates a proposed argument (parameter name element). It returns a string which is the reason the modification is vetoed or null if not vetoed:
collection Set<OtherType> someCollection = new TreeSet<>() {
validateAddTo {
if (someCollection.contains(element))
"Element is already added"
else
null
}
validateRemoveFrom {
if (element.isInUse())
"Element is still in use"
else
null
}
}
The keyword derived defines an expression which is used as getter of a non-persistent (derived) collection. Derived collections have no instance variable and setter.
collection Set<OtherType> someCollection = new TreeSet<>() {
derived {
someCalculation()
}
}
For these collections only the business rule hide is allowed.
The keyword addTo defines an expression to add a given element (parameter name element) to the collection:
collection Set<OtherType> someCollection = new TreeSet<>() {
addTo {
doSomeStuff()
getSomeCollection().add(element)
doSomeOtherStuff()
}
}
Using this method allows business logic to be placed apart from the update of the collection.
The keyword removeFrom defines an expression to remove a given element (parameter name element) from the collection:
collection Set<OtherType> someCollection = new TreeSet<>() {
removeFrom {
doSomeStuff()
getSomeCollection().remove(element)
doSomeOtherStuff()
}
}
Using this method allows business logic to be placed apart from the update of the collection.
With the keyword event a custom domain event (subtype of CollectionDomainEvent) can be defined:
@Collection(domainEvent = SomeEvent)
collection Set<OtherType> someCollection = new TreeSet<>() {
event SomeEvent
}
If the keyword module is present then the generated custom domain event type inherits from a subtype within the domain event type hierarchy instead of the corresponding Isis library type.
The keyword action is used to define a method for an entity. The method expression (which evaluates the return value of the action) is defined with the keyword body:
entity SomeType {
@... // Isis and JDO annotations
action boolean someAction {
body {
true
}
}
}
An action can have additional attributes (supporting methods), e.g. disable:
entity SomeType {
action boolean someAction {
body {
true
}
disable {
if (isBlacklisted())
"Cannot executed for blacklisted entities")
else
null
}
}
}
These features are described in the following chapters.
For actions imperative rules for visibility, usability and validity can be defined. These business rules provide additional checking and behaviour to be performed when the user interacts with those object actions.
The keyword hide defines a boolean expression for hiding the action:
action boolean someAction {
hide {
isBlacklisted()
}
}
The keyword disable defines an expression for disabling the action.
It returns a string with the reason for disabling or null if not disabled:
action boolean someAction {
disable {
if (isBlacklisted())
"Not allowed for blacklisted entities")
else
null
}
}
The keyword validate defines an expression which validates a complete set of proposed action arguments (parameters are the same as for the action). It returns a string which is the reason the modification is vetoed or null if not vetoed:
action Order placeOrder {
validate {
if (quantity > product.orderLimit)
"May not order more than " + product.orderLimit + " items for this product"
else
null
}
}
The action parameters (if any) are defined with the keyword parameter:
action int someAction {
@... // Isis and JDO annotations
parameter int someParameter {
}
body {
someParameter + 1
}
}
An action parameter can have additional attributes (supporting methods):
action int someAction {
@... // Isis and JDO annotations
parameter int someParameter {
default {
5
}
}
body {
someParameter + 1
}
}
These features are described in the following chapters.
The keyword default defines an expression which returns the initial argument value for this property:
parameter int someParameter {
default {
5
}
}
The keyword choices defines an expression which returns a collection of values for this property. These values are used for populating drop-down list boxes:
parameter int someParameter {
choices {
#[1, 2, 3]
}
}
The keyword complete defines an expression which returns a collection of values from a properties drop-down list box for a given search string (parameter name is search):
parameter int someParameter {
@MinLength(3)
complete {
switch search {
case 'min' : #[1, 2]
case 'max' : #[2, 3]
default : #[]
}
}
}
The optional annotation @MinLength specifies the minimum number of characters that must be entered before the auto-complete method is called
The keyword validate defines an expression which validates a proposed value (parameter named value). It returns a string which is the reason the modification is vetoed or null if not vetoed:
parameter int someParameter {
validate {
if (value < 0 && value > 10)
"Proposed value out of bounds"
else
null
}
}
With the keyword event a custom domain event (subtype of ActionDomainEvent) can be defined:
@Action(domainEvent = SomeEvent)
action someAction {
event SomeEvent
}
If the keyword module is present then the generated custom domain event type inherits from a subtype within the domain event type hierarchy instead of the corresponding Isis library type.
Domain services, factories or repositories are defined with the keyword service. They have a unique name and are preceeded by Isis or selected JDO annotations.
@... // Isis and JDO annotations
service SomeService {
}
By using the keyword extends a service can inherit from another service:
service SomeService extends SomeSuperType {
}
With the keyword inject an Isis service can be autowired (field injection) into a service:
service SomeService {
inject OtherTypeRepository others;
}
Services support the same kind of actions like entities, e.g.
service SomeService {
@... // Isis and JDO annotations
action boolean someAction {
body {
true
}
disable {
if (isBlacklisted())
"Cannot executed for blacklisted service")
else
null
}
}
}
Service actions have the same features as entity actions:
Behaviours (Mixins) are defined with the keyword behaviour. They have a unique name and are preceeded by Isis or selected JDO annotations.
The parameter of the behaviour's single-argument constructor is defined after the keyword for.
@... // Isis and JDO annotations
behaviour SomeBehaviour for SomeObject obj {
}
By using the keyword extends a behaviour can inherit from another type:
behaviour SomeBehaviour for SomeObject obj extends SomeSuperType {
}
With the keyword inject an Isis service can be autowired (field injection) into a behaviour:
behaviour SomeBehaviour for SomeObject obj {
inject OtherTypeRepository others;
}
Behaviours support the same kind of actions like service, e.g.
behaviour SomeBehaviour for SomeObject obj {
@... // Isis and JDO annotations
action SomeObject $$ {
body {
obj
}
disable {
if (isBlacklisted())
"Cannot executed for blacklisted behaviour")
else
null
}
}
}
Behaviour actions have the same features as service actions: