Home
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