Modules enable the logical separation of user interfaces and application logic. It divides your application into smaller components, increasing reusability, improving runtime performance through dynamic loading, and improving maintenance.
Add a new module by pressing the plus button in the top right corner.
Set a Name and a Description. The Default Language is American English; you can change it by pressing the drop down. You don’t need to set the Transport-Name, because it is generated automatically. Additionally you can assign projects to your Module.
Now the module has been created and is displayed in the overview. You can search for name, description, author or framework.
On the right side, you have the usual possibilities. You can edit the module, which leads you to its UI Designer, switch to the preview, or delete it. There is also the option to edit the description, copy the module or show the module usage in apps, which allows you to jump directly into the application by clicking on it.
Within the editing of the modules, you have almost the same possibilities as in the editing of applications.
By editing the module, you get directly to the UI Designer. You can switch to the App Wizards, Data Workbench, Interfaces and Others.
| Dependencies/Scripted Widgets | All dependencies that a module uses will be available within its own namespace as follows: Before: io.simplifier.widgets.Text→ After: <ModulName>Widgets.io.simplifier.widgets.Text→ MyModuleWidgets.io.simplifier.widgets.Text (example) |
| Permissions and Auto fields | A module has its own permissions and auto fields when it is launched standalone, i.e. anonymous logins, user logins, and auto fields, etc. are handled as in a normal app. When the module is loaded within an app, it does not provide its own auto fields or permissions but instead uses the permissions and auto fields of the parent app. |
| Assets (Libraries, CSS, Images, etc.) | When a module is loaded by an app and defines any asset that is also defined by the app itself, the module’s assets are overwritten by the app’s assets. If there is a conflict between the modules, a warning is displayed explaining the merge behavior:
|
| Languages | Translation files of modules loaded by apps are merged into the app’s translation files so that the app’s language files contain all translations. The module’s translation keys are therefore prefixed with the module name, but if a module defines a language that does not exist in the main application, it is not included. |
| Theming | Modules cannot provide their own design, therefore the design of the app is used when loading. |
| FrontendIdentifier | For modules, the FrontendIdentifier cannot be edited and is fixed to the name of the module to avoid conflicts. It is still possible to edit the frontend identifier of apps. |
| Simplifier Client | Modules are not listed in the app list of the Simplifier Client. |
| HTML-Ids Prefixed | HTML elements in modules are always prefixed with the module name to avoid conflicts with elements of the same name in apps. |
Take a look at how to use modules in the Process Designer.
