The release notes from the new version 18.104.22.168 of SpringBot.
This release implemented UI model 2.0 to SpringBot which completely overhauls the current UI implementation. You will therefore need to be aware of the new method of building the UI of your application, as well as steps to migrate your existing applications to this version.
Pages exist as they did before; they are routable locations in your application and contain child components or html. Security is still configured from the security model. Placing objects onto the page, will put them stacked vertically and can be re-arranged.
There are currently two types of layouts; Horizontal and Vertical. These layouts are a way of grouping content and positioning items either down the page or across. Layouts can have any other UI elements nested inside of them, including other layouts. You can therefore use them to build out pages to display content side by side, going down the page or a combination of these.
UI elements are the basic building blocks you will use to construct your pages in the new UI diagram, there are currently 4 categories of UI Elements.
These are basic HTML elements and include:
- Text (p tags)
- Heading (h1-h6 tags)
- List (Unordered)
- Link (a tags)
- Button (button tags)
The button element is unique because it will create a placeholder call-back function for developers to implement their custom logic. Out of the box, it will not perform any action.
- Text area
- Radio Button Group
These inputs use the Angular components which you would expect to find in a Codebots application. They come by default with model bindings on input, so you can perform any operations in response to the users actions.
Extensions are the same as the previous ‘Extension Tiles’ and include ‘Timelines’, ‘Forms’, and ‘Data table’. Adding this to your page and selecting an entity will display the component for this extension in the target application.
Functionally the same as the previous ‘Custom Tiles’, they serve as protected regions for developers to add in any other UI elements or custom Angular components.
For a more detailed information please see our Introduction to the User Interface Article.
No improvements were included.
No defects were resolved.
While V2 is releasing with exciting features, it is not a requirement to upgrade. V1 will still be supported, though no new features will be added. We are therefore giving users the option of upgrading to the latest minor V1 and will continue to release hotfix patches as they are required. If you require a hotfix on one of these older versions, you can request one through the support section on the platform. V1 Will be actively maintained a year following the launch of version 2.0, we will drop active support 13/01/2022.
If you would like to upgrade to V2, please use the Migration path steps below.
Codebots will attempt to migrate your existing models across to the new version 2.0; however if you have custom changes in your target application, these will need to be ported across manually. If you do not have any custom code from UI model V1, then you can skip these steps.
Due to the extensive changes to the structure of the client-side of the application, many files have been removed. Any changes within protected regions in these files will not persist after the update. As such, you will need to transfer changes to the equivalent files in the new client-side structure. Code such as the Crud or Forms tiles are still present, so you will be able to transfer your changes, but it will have to be done manually. After discussing the structural changes we will provide a mapping of removed components and where the code can be found in the new structure.
Old structure of client-side
This structure analysis will only examine sections of the client-side code structure which have been modified for the UI Model redesign. Any directories which were not modified will be denoted as such.
src/app | app.component.html | app.component.scss | app.component.ts | app.module.ts | app.routes.ts | graphql.module.ts | └─── admin //Unchanged | └─── enums //Unchanged | └─── frontend //Unchanged | └─── lib //Unchanged | └─── models //Unchanged | └─── pages | | | └─── *PageName* //One directory for each page in UI Model | | *Page_Name*.page.module.ts | | *Page_Name*.page.routes.ts | └─── services //Unchanged | └─── tiles | | | └─── crud | | | | | └─── *TileName* //One Directory for each Crud Tile | | | *Tile_Name*-tile-crud-routing.module.ts | | | *Tile_Name*-tile-crud.component.html | | | *Tile_Name*-tile-crud.component.scss | | | *Tile_Name*-tile-crud.component.ts | | | *Tile_Name*-tile-crud.module.ts | | | | | └─── edit | | | | *Tile_Name*-tile-crud-edit.component.html | | | | *Tile_Name*-tile-crud-edit.component.scss | | | | *Tile_Name*-tile-crud-edit.component.ts | | └─── list | | | *Tile_Name*-tile-crud-list.component.html | | | *Tile_Name*-tile-crud-list.component.html | | | *Tile_Name*-tile-crud-list.component.html | | | └─── custom | | | | | └─── *TileName* //One Directory for each custom tile | | | *Tile_Name*-tile.component.html | | | *Tile_Name*-tile.component.scss | | | *Tile_Name*-tile.component.ts | | | *Tile_Name*-tile.module.ts | | | └─── form | | | └─── *TileName* //One Directory for each form tile | | *Tile_Name*-tile-form.component.html | | *Tile_Name*-tile-form.component.scss | | *Tile_Name*-tile-form.component.ts | | *Tile_Name*-tile-form.module.ts | └─── views | └─── *ViewName* //One Directory for each View | | *View_Name*-view-routing.module.ts | | *View_Name*-view-form.component.html | | *View_Name*-view-form.component.scss | | *View_Name*-view-form.component.ts | | *View_Name*-view-form.module.ts
New Structure of Client-side
Below is the portion of the client-side file structure relevant to the UI Model update. The majority of files will have the same structure, but have been moved or renamed for the purposes of the UI update. The largest structural difference is in relation to pages, and how their contents are determined. In the previous implementation, pages had a routes file, and that file would determine which tile component was rendered at the specified route. The new UI Model implementation has changed this system. There is still a routes file which determines which code is rendered on the page, however the update has introduced page components. Therefore, the routes file will ensure that it’s associated page component is rendered at the specified route.
Another change which was made was updating the method used to write form and crud components. Previously, a form or crud tile would be written by the bot for every form/crud tile added to the UI Model respectively. However in the updated UI Model, there will only be 1 Crud or Form component for every entity, and adding multiple crud tiles will simply create multiple instances of this same form component.
src/app | app.component.html | app.component.scss | app.component.ts | app.module.ts | app.routes.ts | graphql.module.ts | └─── admin //Unchanged | └─── components | | | └─── crud | | | | | └─── *EntityName* // One Directory for each entity associated with a crud component | | | *Entity-Name*-crud-routing.module.ts | | | *Entity-Name*-crud.component.html | | | *Entity-Name*-crud.component.scss | | | *Entity-Name*-crud.component.ts | | | *Entity-Name*-crud.module.ts | | | | | └─── edit | | | | *Entity-Name*-crud-edit.component.html | | | | *Entity-Name*-crud-edit.component.scss | | | | *Entity-Name*-crud-edit.component.ts | | └─── list | | | *Entity-Name*-crud-list.component.html | | | *Entity-Name*-crud-list.component.scss | | | *Entity-Name*-crud-list.component.ts | | | *Entity-Name*-crud-list.component.spec.ts | | | └─── form | | | └─── *EntityName* // One Directory for each form entity associated with a form component | | *Entity-Name*-form.component.html | | *Entity-Name*-form.component.scss | | *Entity-Name*-form.component.ts | | *Entity-Name*-form.module.ts └─── enums //Unchanged | └─── frontend //Unchanged | └─── lib //Unchanged | └─── models //Unchanged | └─── pages | | | └─── *PageName* //One directory for each page in UI Model | | *Page_Name*.page.component.html | | *Page_Name*.page.component.scss | | *Page_Name*.page.component.spec.ts | | *Page_Name*.page.component.ts | | *Page_Name*.page.module.ts | | *Page_Name*.page.routes.ts | └─── services //Unchanged | └─── tiles | └─── *TileName* //One Directory for each custom tile | *Tile_Name*-tile.component.html | *Tile_Name*-tile.component.scss | *Tile_Name*-tile.component.spec.ts | *Tile_Name*-tile.component.ts | *Tile_Name*-tile.module.ts
Migrating Components to New Structure
This section will discuss how you can migrate the changes in your current application to the new UI Model structure. As there have been extensive changes made to the structure of the client-side, you should assume that all protected regions in the modified directories will not be present following the update to the new model. Each of the headings below will correlate to a location in the old UI Structure where custom code could be present, and will discuss our recommendations for migrating your custom code from the location to the new structure.
The code and directory structure for the crud component in the new UI Model is identical to the structure in the previous UI Structure. The only difference is that the location and file names have changed, and the method used by the bot to write the files has also changed. Any unique logic present in your current Crud Tiles can be copied across to the Crud Component for the relevant entity. There has been no changes to the protected regions in these files, so you will be able to copy the code across with minimal issue.
Everything said before about the migration of the Crud tiles to Crud Components also applies to migrating Form Tiles to Form Components, as the code and directory structure of the Form Component is also identical to the Form Tile, with the only differences being the location of the code and the method used by the bot to write the files.
Any Unique custom pages which have been created as part of your web application will be able to be migrated to the new UI Model structure with minimal effort. When creating your new UI Model, you can create a page and add a custom component to it. Adding the custom component will add a protected region to the HTML file for the page you have created, which will allow you to copy your custom HTML to the new page. When a page is created, it also has associated
module.ts files. These files have protected regions where you will be able to add any custom logic, styles, tests, or imports which your code requires.
As an alternative to this, if your custom tiles/components/pages are in files which you have created yourself (If you are not sure, any files written by the bot will have a bot-written warning at the top of the file), they will not be deleted by the bot when it rewrites the application, and you can use them in their current state. Custom tiles or components can be added to any tile or page created by a bot by adding a custom component to the UI Model and instantiating your custom component in there. Any custom pages can be added to the application by adding their routing to
src/app/frontend/frontend-routing.module.ts. This file was not updated in the UI Model changes, so any custom pages you have added should still be present.
Migrating custom code added to views might not be as straightforward as migrating custom tiles, but the process is largely the same. Any HTML can be copied into a custom component, which can be added to a page or tile from the UI builder on the platform. Any page or tile which you migrate these changes into will have the appropriate protected regions which will allow you to migrate any additional logic to the new UI Model structure.