Dynamo: Training

Before you can commence with the training proper, please verify that you have the following software installed on your machine:

The application uses a PostgreSQL database. For this to work, you will need to install PostgreSQL on your local machine or run it in Docker.

To use Postgresql as the database system on your local machine, first download the latest version 15 Postgresql distribution from http://www.postgresql.org/download/. The installer is straightforward, but make sure that you write down the administrator password that you enter during the installation process.

The Postgresql distribution comes with a simple database client named pgAdmin. After the installation is complete, open pgAdmin. You should see a database server configured at port 5432. Connect to this server (using the password you entered earlier) and create a database named “gts”.

You do not have to manually add any tables to this database for now – these will be created as part of the application start up process if they are not there yet.

You will need to clone to Git repositories containing the project source code

IN BOTH CASES YOU WILL NEED TO CHECK OUT THE DYNAMO-TRAINING BRANCH

If your Postgresql settings are different from the default, open the “application.properties” file from the gts-web project and modify the application.properties file from the gts-ui project and modify the following properties so that they match your values:

Once you have imported the backend project in your IDE, you will see a fairly typical Spring Boot application.

We have already created the domain objects, DAOs, and service classes for you.

When you look inside the com.opencircle.gts.domain package you will see a number of classes that together make up the domain model of our example application. These include:

The domain model also uses a class named Country which is taken from the Dynamo framework, more specifically from the dynamo-functional-domain module. This module is covered in more detail later.

When you look inside the com.opencircle.gts.dao package and its subpackages, you will see several Data Access Objects (DAOs) used for communication with the database. Typically, there is a DAO interface and an associated implementation for every entity class, although for some dependent entities that are never retrieved/stored directly a DAO is not necessary.

In the example application used for this training, we use almost no custom logic, so the DAO interfaces are typically simple:

In the easiest scenario, all you have to do is extend the BaseDao interface provided by the framework. This BaseDao contains several dozen utility methods for saving, removing and retrieving entities.

When you look inside a DAO implementation class, you will see that it is also quite simple:

As you can see, the DAO implementation extends the BaseDaoImpl class (which, unsurprisingly, implements BaseDao) and must implement the DAO interface. In its most basic form, you only have to implement the (trivial) getEntityClass() and getDslRoot() methods – the latter returns the root path used when creating QueryDSL queries.

QueryDSL is a library that we use for type-safe custom queries. It is a very useful technology which we encourage you to learn about online, but it is outside the scope of the training.

For now, this is all you need to know about DAOs in Dynamo applications – the basic functionality is both quite simple and quite nicely hidden behind several layers of abstraction, so you don’t normally have to bother with it all that much.

Inside the com.opencircle.gts.service package you will find the service layer for the GTS application. Like the DAO layer, this is a simple layer as since at the moment it contains almost no business logic. As with the DAOs, there is one service interface and one corresponding implementation per entity class (and again, for dependent entities you don’t have to create a service).

If you look inside the GiftService class, you will see the following:

As you can see, all a service interface must do is extend the BaseService class – this gives the service access to the common methods for retrieving, storing, and deleting entities.

The GiftServiceImpl service implementation class is also quite simple:

All it needs to do is extend the BaseServiceImpl class (that, of course, contains the implementation of the common methods) and implement the corresponding service interface.

It then needs a reference to the data access object (GiftDao) which can simply be injected as a Spring dependency, and an implementation of the getDao() method which will simply return the DAO.

Most of the methods from the BaseServiceImpl are delegate methods which directly forward the call to the BaseDao method, but the service layer does add some functionality:

After you have imported the projects into your IDE, make sure they all build properly. Then, open the GtsApplication class and run it.

In order to run the front-end, open a command prompt and navigate to the root folder of the front-end project. Execute the following to start the application.

Then open a web browser and navigate to http://localhost:4200.

You will see a mostly empty screen, and be given the option to log into the application (either via the button in the top right, or by pressing the button on the login screen).

TODO: Authentication using something other than SSO for the training?

After logging in, you will be able to view your first screen, which is a search screen that allows you to view the organizations that are stored in the system (we already created some by means of the creation script).

This screen is an example of the GenericSearchLayoutComponent. This component consists of a search form with a results grid, from which you can select an entity and navigate to a detail screen (which is a separate page/component in this version of Dynamo).

The code for this search screen is included in the organization-search folder. This folder contains both an HTML file and a Typescript file. The HTML file is very small and looks as follows:

The Typescript file possibly even simpler, at least for now (although we will be adding to that later).

While there is a lot you can (and will) tweak, this is basically all that is needed to create a simple search screen. In the next section, we will tweak this screen and make sure it performs as desired.

The first thing you may notice about the screen is that, although it is a search screen, there currently aren’t any search fields. This is because none of the attributes are currently marked as searchable.

To change this, we need to modify the entity model generation process, by means of the @Attribute annotation. This is an annotation that can be placed on a property or on a getter method and can be used to tweak how the entity model is built.

Open the Organization class and place the @Attribute annotation on the name property. Then set the searchable setting to ALWAYS:

Restart the back-end application refresh the browser screen. You will now see a search form that contains a "Name" field to search on. Experiment with the searching to find out that by default, the searching is not case-sensitive and will look for matches anywhere in the attribute value.

You can change the default search behaviour by modifying the following settings on the @Attribute annotation:

This is what it looks like in the code:

Now, set the searchable setting to ALWAYS on some of the other attributes.

You will see that depending on the type of the attribute, a different search field (or combination of fields) will be generated:

Now, play around with the search form functionality for a bit if you want, and when you feel comfortable with how it all works, move on to the next section.

Finally, you might be wondering why we are setting searchable to ALWAYS rather than just “true”. This is because it’s also possible to specify the value ADVANCED. In this case, the property will only show in the search form when the “advanced search mode” is enabled. To try this, change the searchable attribute for “headquarters” to ADVANCED. Now, when you restart the application, the headquarters search field should no longer appear.

Next, in organization-search.component.html file, change the code so that the line referring to FormOptions looks as follows:

You will now see an additional button show up in the button bar. Clicking it will toggle between showing and hiding the search fields that are set to searchable=ADVANCED.

Go ahead at set the searchable setting on the members attribute to ALWAYS. After you do this and restart the application, you will see that there now is a component that allows you to search for the members (to be interpreted as: search for all organizations of which the selected person is a member).

You will now see a search component for the members attribute that looks as follows:

By default, the application will render a multiple-select field from which you can select the members to search on. However, as you can see, the description of the members is currently empty.

To fix this, open the Person class and, at the top of the class, add the @Model annotation like this:

@Model is like @Attribute except that it has to placed on the entity, rather than one of its attributes. @Model supports several settings:

As you can see, by default the application will use a multi-select field for searching inside a many-to-many or one-to-many relationship. You can modify this behaviour by changing the value of the selectMode and searchSelectMode settings on @Attribute:

Go ahead and set the searchSelectMode setting of the members field to LOOKUP. Restart the application and verify that you now see the following:

You will now see a “lookup field” which consists of a label that displays the currently selected value(s), a button for clearing the currently selected value(s) and a button that brings up a search dialog when clicked,

We will end this section with some additional remarks about searching:

We now have a search screen that allows us to search on most fields, but if we look at the screen there are still several things not in order:

Luckily, the framework contains several ways of tweaking the visual and textual representation of the generated screens.

First, let’s go back to the @Attribute annotation. Like @Model, it has the displayName, and description values that can be used to modify the captions and labels that are displayed on the screen. Go ahead and use these to fix the caption of the “Headquarters” search field.

Next, let’s change the attribute order – go to the Organization class and add the @AttributeOrder annotation to the class as seen below

Restart the back-end to verify that the attributes are now displayed in the order specified above – note that this goes for both the search form, the results grid, and the edit screen (which you will see later). Also, note that some fields like “country of origin” do not show up yet in the grid, but we will cover this later.

By default, the attribute order is used to determine the ordering in both the edit form (more on this later), the results grid, and the search form. If you would rather use a different attribute order for your search form or the result grid, you can use the @SearchAttributeOrder or @GridAttributeOrder to specify this.

In the above example, we have added an @GridAttributeOrder. When you restart the application after this, you will see that the grid starts with the "memberCount" and "yearlyMortalityRate" fields.

OK, now it’s time to fix the enumeration. Open the messages.properties file and add the following:

Restart the application and see how the enumeration values have now been replaced by the values from the message bundle.

It can happen that you run out of room in a grid, i.e., you don’t have enough horizontal room to display the full descriptions of all attributes in the grid. In this case, you can limit the maximum length of the value of an attribute inside the grid by setting the maxLengthInGrid setting. Try this for the name attribute:

Restart the application and verify that the values inside the name column are now truncated after 10 characters.

Now that we are talking about message bundles, it is a good moment to point out that (almost) anything you can do by means of the entity model annotations like @Attribute and @Model can also be achieved by means a message bundle. For this, we use the entitymodel.properties message bundle.

Open this file and add the following line:

Restart the application and verify that we now see a percentage sign (“%”) near the values of the “yearly mortality rate”. This teaches us the following:

You can also directly change the settings on the entity by not including a property name, e.g. Organization.displayName=Organisatie

You can also change the value of the percentage setting using the @Attribute annotation – this is just an example to show you that you can also change it by using the message bundle.

To practice a bit more, add the following lines to entitymodel.properties.

Then, restart the application and verify that instead of the standard "true" and "false" values for the Boolean governmentSponsored attribute, you will now see the custom descriptions shown above.

The exact syntax and all the names of the settings you can tweak is an advanced topic and is covered in more detail in the Dynamo manual. For now, the most important things to remember are:

Now, let’s go back to the countryOfOrigin attribute. We want to display this attribute in the grid, but it’s not there yet. This is because it is a complex attribute that refers to another entity or collection of entities. By default, this type of attribute is not shown inside a table. To fix this, add the @Attribute annotation to the countryOfOrigin property and set the visibleInGrid setting to SHOW.

Now, after you restart the backend application, the country of origin column should appear in the table. Note that the displayProperty of the country is already set to the name property.

The way the data is fetched is not very efficient right now. For every organization, that application performs an extra query in order to retrieve the country.

In order to fix this, we can add a fetch join to the data retrieval. To do so, add the following annotation to the Organization entity:

This will make sure that whenever any Organizations are fetched by the framework, the countryOfOrigin relation of those organizations will be fetched as well.

Fetching is an important concept in the Dynamo framework since it is a powerful way to limit the number of queries that is carried out and can thus be crucial for achieving good performance. Keep in mind though, that if used poorly it can also lead to a lot of useless data being retrieved with every request – imagine e.g. that the Country keeps track of all its inhabitants: automatically fetching (millions or even billions) of inhabitants every time a country is fetched is clearly a bad thing and must be avoided.

So, figuring out which relations to fetch and which not to fetch (or whether to model those relations in the first place) can be an important design decision.

As you may have noticed, the Country class we have seen before isn’t defined inside the GTS application – instead it comes from a Dynamo module named dynamo-functional-domain. This contains some useful classes for dealing with “domains”, also known as “code tables” or “lookup tables”- they are basically simple entities that only consist of a name, or of a name and a (unique) code.

The module contains several pre-defined domain classes like Country which you can use if you include a database table named “domain” in your application and fill it with the proper values (this is straightforward, so we won’t go into it here).

To properly use the values from the Country table, though, one more thing is needed and that is a service for retrieving them from the repository. Now, we could of course create the proper Java classes for this, but this is slightly tedious, and we can also use the Dynamo functionality for Default Services and define the required service in Spring. Open the ApplicationConfig.java class and take note of the following code:

This defines a bean that is an instance of DefaultServiceImpl which has an inner bean of type DefaultDaoImpl.* These are convenience classes that in turn inherit from the BaseServiceImpl and BaseDaoImpl classes and provide all the basic functionality for retrieving, saving, and deleting entities. The only catch is of course that you cannot define any custom methods (e.g. findCountriesInEurope()) but for such simple entities, this is usually not an issue.

Now, let’s return to the countryOfOrigin field in Organization for a bit. By default, the application will render a dropdown component that can be used to select a country to search on. Let’s play around with this a little bit and change it to a lookup component:

Restart the backend and observe how you can now use a popup dialog to search for the country you want to filter on.

Dynamo now also comes with an auto-complete field which you can use as follows:

With this in place, the application will render a field that allows the user to start typing – the available options will be filtered so that only those that match the entered search term will be returned.

As an extra exercise, set the multipleSearch setting to true. This allows you to search for multiple values for a normally single-valued relation – the search query will return all entities that match one of the provided search values.

In addition to the search form functionality explained above, Dynamo offers an additional way of handling search requests. This is called the Dynamic Search Layout and basically consists of a search form to which search terms can be added dynamically. To enable this functionality add the following in organization-search.component.ts:

And bind it in the organization-search.component.html:

Now, you will see that the search screen you saw before has been replaced by a (normally) initially empty search form, with an Add filter” button below it. Pressing this button will add a row to the search form. This row can be used to add a search criterion.

Each search row starts with a combo box that allows you to select the attribute you want to filter on. It includes all attributes with searchable set to either ADVANCED or ALWAYS, sorted in alphabetical order.

Selecting an attribute from the combo box will cause one or more input components to appear based on the selected attribute (e.g. a text field for a string attribute, two number fields for an integer component etc.). This follows the exact same logic as the regular search form.

When you mark an attribute as requiredForSearching, a row for that attribute will always be rendered; it cannot be removed and the selected attribute cannot change. If you define or more default values for an attribute, then a search row for that attribute will also be displayed, with the default values filled in, but in this case the rows can be removed and values can be added.

We’ve now done about all we can do to make our search screen behave in the desired way, so let’s move on to adding new entities.

As you can see, there is already an “Add” button below the search results grid. If you click this button, the application will navigate to an edit form that allows you to add a new entity (in this case an Organization) to the application. Whether this button appears is in fact dependent on the createAllowed setting on the entity model (but this is true by default).

When you click the “Add” button the application will try to navigate to a separate page. Which page this is, is specified by the detailNavigationPath setting that was mentioned earlier (and which is set to “organization”).

When you look in app-routing.module.ts you will see that the following routes are defined (one for editing an existing entity and one for creating a new one):

Both routes point to the OrganizationFormComponent which looks as follows:

This is a minimal set-up that includes:

By default, the form will already contain some input fields – as with the search fields, the entity model determines which type of user interface component is rendered for which attribute. The edit form looks like this:

By now, it should not come as a surprise that you will see text fields for String and numeric attributes, combo boxes for enumerations, etc. If you look closely, however, you will see that there is no component for editing the countryOfOrigin attribute. This is because, by default, no components will be created for editing complex attributes. There is also no component for modifying the members but this is by design.

To make the components for editing the complex attributes show up, you can set the visibleInForm setting for an attribute to true. We do this now for the country of origin field:

Now, go ahead and add a new organization to the system (be creative).

Now, return to the search screen for a moment, and observe that you can click on any row in the table. This will cause the application to navigate to the detail screen you just saw, but now the details of the selected row will be shown.

You can also set the showDetailButton setting on the generic-search-layout to true. With this setting in place, you can no longer just click anywhere in the table. Instead, a “pencil” button will show up in each row in the table. Click this button to navigate to the detail screen.

Some changes you can make to modify the behaviour of edit forms include:

The above will make sure that the “address” field shows up on the same line as the “headQuarters” field. When using this setting, take care that the attributes are in the right order (the attribute on which you place the groupTogetherWith setting must occur in the ordering before the attribute it refers to. Dynamo will produce an error if you define an incorrect attribute grouping)

The Dynamo Framework also supports the functionality of turning certain fields into clickable URLs (that point to external resources).

To demonstrate, set the url setting to true for the url property of the Organization class.

Then, restart the application and verify that in the grid in the Organizations screen you will now see an empty “URL” field. Navigate to the edit screen and fill in a value.

Enter some valid URLs for some of the Organizations, then look at the search results grid and check that the URL column now contains clickable links that can be used to take you to directly to the pages identified by the URLs you entered.

The clickable URL field will also show up inside a detail view that is in view mode (more on view mode below).

By default, an edit form will contain just a single column containing the input fields. It will also not take up the entire width of the screen. Both of these things are fairly easy to change.

In order to change the width of the entire form you can set the value of the formWidthClass property on the app-generic-form. This property expects standard Bootstrap expressions, e.g. col-12 means use up all 12 available columns

If you want to change e.g. the number of columns being used, you can modify the numberOfColumns property. By default, this has the value 1, but you can set it to 2 or 3. Using a value other than 1 will cause the input components to be displayed behind each other on the same row (provided there is enough room).

By default, all attributes inside an edit from will be displayed below and behind each other, in the order specified by the @AttributeOrder annotation you saw before (with an exception for the attributes that have been mentioned in the groupTogetherWith setting). However, sometimes, especially when you have many attributes, it can be useful to have a way of grouping certain attributes together.

To demonstrate how this works, add the following annotations to the Organization class.

Here, you define two attribute groups identified by the message keys “organization.first” and “organization.second” and place some attributes in each group.

In the entitymodel.properties file, add the following lines:

Restart the application and verify that the edit form now looks as follows:

You will see three attribute groups: the two groups you declared and an additional group that contains all attributes that were not explicitly assigned to any of the groups.

Also, by default the application will use panels to group the attributes together. If you prefer using tabs, define an attribute group mode property in your Typescript file:

And refer to that property in the HTML file (organization.form.html).

After you restart the application you should now see three tab sheets (each containing a number of attributes) in the detail screen.

By default, the option to delete existing entities is disabled. You can easily enable this functionality by setting the deleteAllowed setting on the @Model annotation to true.

With this setting in place, the application will now render a big bright red “Delete” button in every row in the search results table.

As an alternative to using a separate detail screen, it is also possible to open a pop-up edit dialog directly from the results table. In order to enable this functionality, define a popupButtonMode variable in organization-search.component.ts:

then use it from the HTML file to bind it to the . This will cause a “details” button to appear in each row in the details table. Pressing this button will cause a pop-up dialog containing the details of the selected entity to appear. The fields that will appear in this pop-up dialog are rendered according to the same logic as the edit form (e.g. this will mean the same attribute groups, ordering, etc. will be used). However, some of the options that are available on the full edit form (e.g. setting the number of columns) are not available in the pop-up dialog.

The value EDIT chosen above will ensure that the dialog will be opened in EDIT mode. You can also specify the value VIEW. In this case the pop-up dialog will be rendered in read-only mode. The default value, NONE, means that no button to open the dialog will appear.

There are several more options available on the GenericEditFormComponent to govern how the component behaves:

There are several more options available on the GenericSearchLayoutComponent to govern how the component behaves:

It is also fairly easy to define your own lookup tables. As a case in point, take a look at the “MainActivity” class. This defines the main activity of an Organization. In order to use it in the application, modify Organization.java so that it reads as follows:

Also, set the displayProperty of the MainActivity class to name.

Now, when you open the detail page for an organization, you should see a “Main Activity” field in the edit form:

Behind the input component, you will see a “plus” button that allows you to quickly add a new value for this lookup table. This button appears because you have set the quickAddAllowed setting to true. Clicking the button will bring up a dialog that allows the user to create a new entity. If the creation is successful, the new entity will be added to the list of available options in the component, and selected.

Dynamo contains automatic protection against entering duplicate values – when you try to add a new lookup table value with the same name as an already existing entity, the application will throw a validation exception. The message that is shown is expected to be in the message bundle under the <DomainName>.not.unique key. To make this work for the MainActivity, add the following to entitymodel.properties.

Now, restart the application, try to add a duplicate main activity and verify that you see the error message defined here.

The attribute model currently support around 60 separate settings. Although we refer you to the Dynamo manual for a complete listing, it’s good to briefly outline some additional settings here:

Now, let’s move to the Person entity which is used to represent the various members of the criminal organizations we are interested in.

As with the Organization entity, the entity class, DAO, and service classes have already been provided for you. We will, however, be adding a new Angular component. First, create the skeleton for the component by running the following Angular CLI command:

This will generate an Angular component (4 files in total) and add it to the application’s main module.

In the app-routing.module.ts file, add the following to the children array:

This defines a new route to the persons component. Finally, in the nav.component.ts file, add a new menu item:

Which will add a new top-level menu item named “Persons”. If you click on this link, you will be taken to a page that simply reads “person-search works”, the Angular default.

We will now replace this default implementation by a Split Layout. This is a layout that consists of a search results table on the left and a form for displaying the selected row on the right. Implementing it is even simpler than for the search layout:

Which will produce a screen that looks as follows:

Now, using everything you have learned so far, modify this screen in the following ways:

that has not been done already). * The attribute order reads firstName, nickName, lastName, organization, born, died. * The caption for the nickName property must be changed to “Nickname” * The "Remove" button must be displayed for each row in the table.

Play around with the screen a bit and add, edit, or delete some entities.

By default, the data that is displayed is not filtered in any way. You can change this by adding default filters to the layout. These are filters that are automatically applied to any search request. In order to add default filters, define the following in the person-search.component.ts:

This sets up a filter for filtering on the firstName property of the person, and will match if this first name contains the letter “a” (note that the attribute model, specifically the searchPrefixOnly and searchCaseSensitive settings determine how exactly the search is carried out. You don’t have to specify a “like” query or something in the front-end.)

The Dynamo framework comes with a range of built-in filters. In addition, the EqualsFilterModel shown above, there are classes like NumberRangeFilter, DateRangeFilter and NumberInFilter. Please refer to the full Dynamo documentation for more details.

Like the GenericSearchLayout, the GenericSplitLayout comes with a number of useful properties that can be used to modify its behaviour. Some of these include:

The split layout also supports settings like openInViewMode and confirmSave that we already covered when discussing the GenericSearchLayout.

So far, you have only seen occasions in which a combo box or other lookup component contains all the available values. In a small application like this, that is usually not an issue, but in a real application it is likely that you sometimes want to restrict the values that show up inside a selection component or lookup component. For this you can use the field filter mechanism.

As we’ve seen before with the default filters (in the SplitLayout), the field filters are defined in the component’s TypeScript file. As an example, we define the following in the organization-form.component.ts

Also, in the HTML file we bind this method to the [fieldFilters] property.

Now, if we open the screen to edit an organization (or create a new one), we will see that the available option in the countryOfOrigin component are limited to those countries that contain the substring au (e.g. Austria or Australia). This works regardless of the type of the input component, but it will of course show up in different ways.

The example above only applies to the edit form, but adding the field filters to the search form works in exactly the same way.

While the Dynamo framework has some fairly robust options to modify the way in which input components behave, it is possible to override the standard component generated by the framework with a custom one.

To do so, you can insert an ng-template element marked with the dOverrideField annotation inside the component (in this case, organization-form.component.html.

The dOverrideField on the template makes sure the mechanism picks up this custom component. The “attributeName” must be the name of the attribute for which you want to replace the input component.

Inside the template you can create basically any component you like. Make sure to nest the custom component inside a formGroup though, or no data binding between the model and the component will take place. Also don’t forget to set the formControlName property to the name of the attribute.

Using custom components like this is also supported for the search layout (when in “standard” mode), the split layout, and the editable table layout.

In addition to adding custom components, it is also possible to add custom validators to the default Dynamo components.

As stated before, the framework will take care of adding validators to the front-end based on the Java Validation API annotations like @Min, @NotNull, @Size etc. In case this is not enough, it is of course possible to provide your own validation logic in the back-end, but this functionality cannot be automatically duplicated on the front-end. This is where custom front-end validations come in.

We have already provided a custom validator in the CustomValidators class, and will now apply this to a field in the person-search.component.html that we created before.

In the app-generic-split-layout we created before, we add a template named customValidatorTemplate and bind this to the customValidatorTemplate property of the layout:

Inside the template we can create any number of templates annotated with the dAdditionalValidators template. Each template must contain the following:

In the typescript file, add the following, where the CustomValidators on the right refers to the class you import from the custom-validators.ts file.

As you have probably seen, many of the composite components offered by the Dynamo Framework contain button bars that contains buttons to e.g. add entities, switch the component to edit mode etc. It is possible to add additional buttons to these button bars in several ways.

The first way is by means of the back-end, using the concept of Entity Model Actions. These are basically methods that are added to your service layer that are exposed to the front end as part of the entity model.

In order to add an entity model action, we need the following things:

Let’s start with the DTO:

The DTO class must extend the AbstractEntity class, and must have an ID field that has the same data type as the entity that the action belongs to (in this case the Organization). The framework constructs an entity model for the DTO in the same way as it does for an actual entity, so annotations like @Model and @Attribute work in the same way.

In the OrganizationService(Impl) we add the action method that we want to carry out:

And in the OrganizationService we add the method definition

This is a fairly simple method that accepts the OrganizationNameDTO as a parameter, and must return the updated entity (in this case the Organization). The logic is easy – it just sets the name on the organization, then saves the updated organization to the database.

As you can see the method is annotated with @ModelAction which means Dynamo will translate it to a button that will show up (in this case) in each row in the table. The ModelAction has a unique ID, a display name (which will be shown in the tooltip of the button) and a type.

The type can be either CREATE or UPDATE and determines where the button corresponding to the action will show up. UPDATE actions will show up in each button in a results table, and CREATE actions will show up in the button bar below the table.

Pressing the button will open a pop-up dialog based on the OrganizationNameDTO we saw before. Any fields that match between the main entity (Organization) and the DTO, in this case the name, will be automatically filled in:

In addition to this, you can also add actions/button that are managed on the front-end. These come in three varieties:

As an example of a global action, consider the following code which we add to organization-search.component.ts).

A global action consists of:

Now, if you look at the Organization screen, a button will show up below the result table, and clicking it will display a notification message.

Adding form actions and row actions goes in much the same way, although the exact attributes differ based on the action type. Refer to the full Dynamo documentation for more information.

The Dynamo Framework offers some functionality for automatically exporting data that is displayed in results grid to Excel (.xlsx) or CSV format.

This functionality is enabled by default. It can be turned off on an entity model by entity model basis by setting the value of exportAllowed on the @Model annotation to false.

If exporting is enabled for an entity, a context menu will show up in any results table (in you right-click anywhere in the table). This menu will contain the options to create exports to both Excel and CSV formats.

The export file that will be created contains all the data in the result set (i.e., all data that matches the search criteria), not just the rows that are currently displayed – Dynamo will iterate over the entire data set using pagination.

By default, the export will contain only the columns that are visible in the table, but you can change the exportMode setting to FULL in order to include all attributes that have their visibleInForm setting equal to "true".

For some properties, it is possible to change the default way they are displayed (simply as a text or a label) inside a grid or an edit form to a hyperlink that allows navigation within the application.

We will demonstrate this using the organization property of the Person. Change the code inside the Person class so that it reads as follows:

This will lead to the following situation in the Person screen (note that you may have to set the openInViewMode to true in order to make the link show up).

The navigable setting on the @Attribute annotation will make sure that whenever the property is shown in read-only mode, a hyperlink will be rendered instead of just a textual representation. Note that this applies to both detail forms and result tables.

When the user clicks the hyperlink, the application will navigate to a (detail) screen by following the route /[lower cased name of the entity]/[entity id], in this case /organization/1. This is the route at which we configured our OrganizationFormComponent so the application will then show a details screen for the selected organization.

In case you want to navigate to a different detail screen, you can set the navigationLink setting on the attribute model in order to configure a different route.