While creating your application model Skipper can automatically create some elements for you. In these situations it is necessary to tell Skipper how the new elements should look like. To do this Skipper uses model elements templates. These templates are fully customizable.
The templates have various uses and can be very complex, but when properly set they can save you lots of time. For example you want to set up the Skipper so you will have the primary key defined automatically for all new entities together with createdAt and updateAt columns.
To have all future entities set up like this with just one click, you only need to add following template to your configuration files:
Thanks to the configuration structure of Skipper you can have at once several set of templates that can be different for each project or each ORM Framework. Check the articles about configuration files and xml configuration file structure for more details how the configuration is applied and how to modify it.
Predefined template library
Most common and most useful templates are already defined and published in the template library. There you can check the examples of templates prepared for real production application.
Templates are defined in the XML format. You can define for what entity the template will be used, when it will be used and of course what values will the template apply. Template definition looks like this:
This is a header for a template. It contains
element (template type),
use-case (context) and
Note: Selectors are only used in special cases. More on selectors later.
element='' parameter specifies for what type of element the template will be applied. In Skipper, you can define template for every element used in the model.
Enumeration of types: Project, Module, Region, Entity, Comment, Association, Many-to-many, Inehritance, Index, Field, Many-to-many-entity, Inheritance-Parent, Inheritance-Child
Structure of the templates is the same as the structure of the project. More about template types and their structure can be found in the template reference guide.
Template context (use-case)
Template context defines when the template will be applied. You can set different templates for the same type of element depending on whether the element was created or changed.
|use-case||used when||use frequency|
|create||user creates an element (before the editor window opens)||used only once|
|update||user applies changes to an element (when the editor window is confirmed)||used repeatedly|
Note: When the new element is created, not only the
create template, but also the respective
update template will be used after you close the dialog to save changes.
create is used when a new element is created from the GUI. Every time you create a new element or a new relation, Skipper will check if a
create template exists for that element. If the template exists, it will be applied.
The following template will be applied to all entities created in the project. Their name will be set to “newEntity”, and the “id” field and its settings will be added automatically.
update is used when an element is modified from the GUI. On-update templates are applied whenever changes are confirmed in the Element Editor. This is most useful when your templates use some substitution marks for the attributes or fields.
You want to ensure that for each entity its table name will always be: ‘ModuleName_EntityName’. The value will be updated every time you change the name of this entity (when the editor closes). The template will look like this:
update template is executed when entity object is changed. This means that if you change the name of the module, the change will not be propagated until you edit the entity again and confirm the changes in the dialogue.
Whenever you create or update an element and it is necessary to create or update related elements automatically the selector is used to define the template. This applies for creating new project, importing a project and creating or updating relations in your model.
|selector||allowed element||used when|
|project_new||project||new project is created|
|primary_field||field||project is imported|
|association-field||field||association is created|
|discriminator-field||field||inheritance is created|
|many-to-many-field||field||many-to-many is created|
|many-to-many||entity||many-to-many is created|
Following template will be applied when the project is imported from the schema file. For all entities without primary key the key will be automatically added and its properties set up.
Following template will be applied when association is created. It will automatically name the association field created inside the owner entity. Notice that you do not have to modify the owner entity manually, the
association-field template will do the work for you.
If you want to have the names for fields or attributes to follow name rules without extra work, or you want certain properties using variable values, you can set up templates with substitution marks and naming styles. When the source element or relation changes the change will be reflected in the name variable automatically.
Substitution marks are used to automatically fill in the values of defined attibutes. When applied, substition mark will be replaced with the value it is referencing. This is very useful for example when creating relations, you can automaticaly set up association field name or aliases for parrent and children.
Substitution marks are denoted by brackets and list of all available marks is available in the reference guide.
You want the association field for all associations created in the project named as ‘InverseEntityName_Id’. The template will look like this:
Skipper supports several naming styles because each user and project can have their own rules. Following styles are supported at the moment:
||CamelCaseFirstUpper in plural form|
||camelCaseFirstLower in plural form|
||under_line in plural form|
Use these as postfixes together with a substitution markers to generate required result.
In this example we will be creating association field from the entity
Inverse entity with primary key
Case A: This template will result in ‘Inverse_entity_entity_Id’.
Case B: Following template will result in ‘inverseEntity_EntityId’.