Modularize your Apps

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.

Please note: The use of modules is restricted and has some implications.

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: If libraries with the same name and different versions are used in different modules within the same app, all these libraries will be loaded. The library definition therefore determines what happens when running the app. (One could overwrite the other, or both could coexist, based on the include section of the library). CSS is merged in the order in which modules are received by the app generator (randomly). If two modules define the same CSS rule, one wins randomly. The same rule applies to images, .js or other files.
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.