An SJS statement is made of 4 parts :

Only statement name is always mandatory. Other parts may be required or not and SJS will enforce these rules.Some statements dont have any parameter. To summarize, every SJS statement conforms to the following scheme :

where closure is a list of SJS statements. This means that there can be an arbitrary nesting of SJS statements.

The following types are used for SJS argument values :

SJS will enforce argument types. Under certain circumstances, expected argument types are references themselves, in which case, SJS will check their validity. Used reference types can be :

Arguments are defined using the following scheme :

For instance :

icon:'traceable-48x48.png'

Whenever multiple arguments need to be declared, they are coma separated, e.g. :

icon:'traceable-48x48.png', preferredWidth:45

An argument value can be a complex type, e.g. a list :

uncloned:['createTimstamp','lasUpdateTimestamp']

or a map (associative array), e.g. :

ordering:['name':'ASCENDING','firstName':'DESCENDING']

Language artifacts are sometimes optional. Omitting them can improve the reading.

Entity 'Employee', icon:'employee-48x48.png'

Entity('Employee', icon:'employee-48x48.png') {
    string_32 'name'
    string_32 'firstName'
}

Entity 'Employee', uncloned:['name','firstName']

Entity 'Employee', uncloned:'name'

form 'Employee.mainView'

form 'Employee.mainView'

form 'Employee.mainView', model:'Employee'

The argument named custom is a special argument that opens SJS built-in statements to further arbitrary customization. This argument is especially useful to customize generic action instances that are assigned to a view. Another important usage of the custom argument concerns the bean statement that allows to create instances of arbitrary classes.

The custom argument value is a map (associative array).

Supported map value types are :

Regarding List and Map value types, the supported keys and values are :

As a consequence, it is impossible to declare to nest maps into a custom argument value. The following example shows a simple usage of the custom argument on an action definition :

action 'chooseEmployeeAction',
    parent: 'lovAction',
    custom: [autoquery:false,
             entityDescriptor_ref:'Employee',
             initializationMapping:['company': 'company'],
             okAction_ref:'addFromList']

There are certain situations where you need to assign a reference to a custom property. On the previous example, the okAction_ref is such a property as it references another action whose identifier is addFromList (same applies for the entityDescriptor_ref property). In that case, SJS must be aware of the value being a reference to :

Since the custom argument contains arbitrary properties, there is no way for SJS to know for the expected type of the value. That is why a reference property must be sufixed by _ref so that the value is interpreted as a reference to another component.

Whenever a list valued property is _ref suffixed, every of its values is interpreted as a reference.

A map valued property cannot be _ref suffixed itself. But each of its entry can be individually.

Some properties can be declared indifferently as an argument or as a closure. These properties are generally reference properties. Let's take an example.

A vertical split container references 2 views : 1 for the top part (the "top" property) and 1 for the bottom part (the "bottom" property).

You can simply reference existing views by using top and bottom arguments, e.g. :

split_vertical 'Departments.and.teams.view',
    top:'Company-departments.table',
    bottom:'Department-teams.table'

Or you can use closures to define your top and bottom views inline, e.g. :

split_vertical('Departments.and.teams.view') {
    top {
        table(parent:'Company-departments.table') {
            ...
        }
    }
    bottom {
        table(parent:'Department-teams.table') {
            ...
        }
    }
}

Or you can even mix both, e.g. :

split_vertical('Departments.and.teams.view',
    top:'Company-departments.table') {
    bottom {
        table(...) {
            ...
        }
    }
}

Using a closure to define a property value allows :

Using a closure will often be referenced as an inline declaration. The main difference between an inline declaration and a top-level declaration is that the inline one is anonymous, i.e. it cannot be referenced from outside (using _ref suffix for instance). You will typically favorize inlined declarations for parts of the application that are hardly to be reused. On the other hand, top-level declarations are required to be named, thus can be later referenced.

Namespace usage allows to simplify SJS based source code by inferring package names of classes and resources that are produced. This package determination is based on conventions covering best practices about a Jspresso project layout.

A namespace is opened using the namespace statement, e.g. :

namespace('org.jspresso.hrsample') {
    ...
}

The namespace will be applied to all statements that are placed into the namespace scope (between the curly braces).

Using the formerly defined namespace will make thefolowing declarations equivalent (note how the namespace has been applied to the image resource) :

Entity 'City', icon:'city-48x48.png'

Entity 'org.jspresso.hrsample.model.City',
    icon:'classpath:org/jspresso/hrsample/images/city-48x48.png'

When a project is generated using the Jspresso archetype, a default namespace is created using the root package name. All declarations placed into standard SJS ource files are implicitely placed into this namespace.

Whenever SJS finds a "/" (slash) in a resource name or a "." (dot) in a class name, the enclosing namespace is ignored and the resource path or class name is considered absolute (i.e. not relative to the namespace).

Namespaces can be nested. In that case, nested namespace names are concatenated.