Migration guide for Tesler 2.0
On the backend: https://github.com/tesler-platform/tesler/pull/20
- Tables containing the navigation structure were renamed: SCREEN_VIEW_GROUP_DATA to NAVIGATION_VIEW, SCREEN_VIEW_GROUP to NAVIGATION_GROUP. Attributes of these tables and constraints are also changed. If you wish to change core.xml, changelog can be copied from the archetype module (by copying a file or by dropping old tables and copying new changesets within the release changelog).
- The delegation functionality has been removed. The DELEGATION, DELEGATION_VIEW, DELEGATION_VIEW_GROUP tables, and related constructs can be deleted.
- The logic for creating navigation in screen.json files has been changed. Main changes - now there can be no less than 2 daughters in a category, the id field is removed, categoryName is replaced with title, the optional defaultView attribute is added, the optional hidden attribute is added. Examples of screen.json files can be found in the archetype. More details in the project wiki https://github.com/tesler-platform/tesler/wiki/Metadata.-Navigation.
- Changes in the contract with the ui: in addition to the changes that affected screen.json, the id field appeared in the contract - a view the natural key in the format screenName/outerGroupSequence/innerGroupSequence/viewName, for example, doc/1/1/someView. It can be used, for example, to display the current navigation branch (ala breadcrumbs)
On the frontend: https://github.com/tesler-platform/tesler-ui/pull/40
- The contract was changed according to the changes on the back. It is assumed that in the client ui application, you need to rewrite the menu display functions according to the new contract.
- Fixed a typo in the package name io.tesler.model.core.conveter. Check usage in your code.
- Removed the explicit link to User in BaseEntity. Replaced by Long, it is necessary to correct in the client application where getters and setters for this field are explicitly used
- Removed the tie for User and Department in other entities (Responsibilities, FieldComment, ViewLayout). Check usage.
- Marked some of the JpaDao methods as Deprecated. Check usage.
- Moved the woAutoFlush method from jpaDao to TransactionService.
- Added the name of the beans to PersistenceJPAConfig.
- In terms of the methods that operate on the transaction, replaced the injection of one EntityManager with a collection. It should not break functionality when working with one EntityManager, but it is better to check.
What’s New in Tesler Helper 1.1 plugin for IntelliJ Idea
- widget layout field key not defined or hidden in fields
- view is never used, widget is never used
- view has duplicate widgetName
- widget field key duplicate
- popupBc widget is created with quick-fix, if no existing widget can be found
- improved performance, when inspections are started for the whole project
- widget, view and screen names with whitespaces are supported
- concurrency problems, when multiple ides are opened
- "picklist bc to popup widget" inspection is now triggered only for fields with type "picklist"
We introduce Tesler Helper 1.0 plugin for IntelliJ Idea!
.widget.json fields key glutter icon, autocomplete, inspection, navigation to java dto and quick-fix
.widget.json inspection for case, when non-hidden filed is added in fields tag, but not added to layout. quick-fix - auto add to layout
.widget.json inspection for case, when name tag + '.widget.json' and widget file name are not equal. Quick-fix - rename file
.view.json inspection for case, when name tag + '.view.json' and view file name are not equal. Quick-fix - rename file
.screen.json inspection for case, when name tag + '.screen.json' and screen file name are not equal. Quick-fix - rename file
.widget.json field of type "pickList" support - PopupBcName autocomplete, navigation, inspection and quick-fix
.widget.json field of type "pickList" support - pickMap left side autocomplete, navigation, inspection and quick-fix
.widget.json field of type "pickList" support - pickMap right side autocomplete, navigation, inspection and quick-fix
.widget.json field of type "pickList" support - PopupBcNameglutter icon to navigate to widget of this bc that will be open in UI (e.g. widget on same view as main widget view).
.widget.json field of type "pickList" support - inspection to check if PopupBcName widget is not added to main widget view
(Draft) simplified views to roles mapping (video)
Previously you needed to fill the responsibilities table with liquibase. It was a rather complicated RESPONSIBILITIES.sql file. Now we introduce tesler.meta.view-allowed-roles-enabled = true property, that switch tesler to auto-loading data in responsibilities table based on new "rolesAllowed": [] tag in .view.json file. source code
Now commonScreens.json can be deleted from your project if you do not use it. Fill free to make your codebase cleaner =)
Simplified demo project structure (video)
We introduce a simplified "classic" project structure in our demo source code
Spring Data Jpa repository example of usage with Tesler (video)
We provided an example of using "spring data jpa" repository instead of tesler baseDao/jpaDao source code
Simplified tesler data model (video)
Total number of db tables in tesler decreased by ~50% (from 64 to 34)!
In this release we temporarily replace tesler archetype with tesler-demo. In future releases tesler-demo is going to be converted back to tesler archetype source code
See CHANGELOG
Debug mode (video)
During local development, one can now determine any widget name with a few clicks. Determine the widget you see on the screen and find it in your ide in a few seconds
Hot-reload meta (video)
During local development, one can now change metafiles in IDE and view changes in the browser in a few seconds without app restart/rebuild. It is recommended to be used only with local DB.
We introduce tester-starter-parent
<parent>
<groupId>io.tesler</groupId>
<artifactId>tesler-starter-parent</artifactId>
<version>3.0.2</version>
</parent>
Its parent is spring-boot-starter-parent, so you get all benefits of spring-boot-starter-parent now.
When one generates project with https://start.spring.io/ , then spring-boot-starter-parent is used to ease dependency management. Lots of libraries are already tested and we've got their compatible versions listed in spring-boot-starter-parent. No jar hell problems, easy upgrade to new spring version, and so on.
Enums (video)
Enums are now first-class citizens in Tesler. One should consider enums as a strongly typed alternative to LOV's. What does "strongly typed" mean for developers? The compiler now helps you to make fewer mistakes. IDE helps you with autocompletion and highlighting problems before compilation. No liquibase/csv changes are needed to add/edit enum, and so on and so on.
We now recommend you to use LOVs only if you are absolutely sure, that you will need the ability to change dictionaries directly in production. Always use enums now, if your java business logic uses some dictionary (e.g. you cannot change dictionary in production, because this will break your logic). In all other cases, we suggest you use enums too
Generate project from archetype:
mvn archetype:generate -DarchetypeGroupId='io.tesler' -DarchetypeArtifactId='tesler-simple-archetype' -DarchetypeVersion='3.0.2' -DgroupId='groupId1' -DartifactId='artifactId1' -Dversion='1.0.0'
Then run 3 commands from readme.md. That is all. The app is ready!
We included a docker-compose file with all needed infrastructure (keycloak, Postgres). So you do not need to pre-install or configure anything now
Archetype and your favorite IDE (video)
We refactored archetype to support rebuild and start backend directly with IDE
Previously we suggested building and starting the app during local development with maven. But for most cases it is much faster to build/start the app with IDE (for example IntelliJ IDEA "knows" what files the developer has changed and can incrementally recompile only them. Which is extremely faster for huge projects)
We do not want to be legacy upgraded spring-boot to 2.5.1.
See CHANGELOG