Cleaning - refactoring Vue.Js component and Title in Field

31 mars 2020

This two months, three main points

  • a lot of work to clean all the older test and trying to homogenize all Vue.Js components,

  • at the field level, direct manage title, so a more material design UI,

  • a lot of finishes for the contactMech component so a very nice screenlet

POC VueJs

Review & Refactoring

After the two main first agile steps, a lot of try-error have been done and the first solution found to solve a technical point was’nt the good one all the time.
After one month of usage by the user (on a tiny functional perimeter), it was time to clean work before next step

  • remove all code associated to "no-more used options"

  • homogeneization of code in all the generic components

  • clarification in field name, computed and method

  • commonUilLabel available in all components

  • some module upgrade, some remove for un-used, and icon handling result in a better build performances.

Enhancement

  • manage help field text as tooltips

  • manage textArea field

  • new uri (and a groovy) to be able to send all CommonUiLabel necessary to Vue.Js generic component, load only at the first application load on browser.

Material Design for field

With Material Design, in single form, find or edit, title is included in the field, in our component it was difficult to use all the vuetify-field functionalities, because title was send at the same level than field ( FieldRowTitleCell and FieldRowWidgetCell ).

FrontJsFormRenderer has been modified to have the Title properties in Field properties, so json send is more simple and field rendering by vuetify is nice.

Currently we have choose to not manage all text-field attributes, only those for which we have a use case and which seem necessary, for example: size attribute seem to not be be necessary with vuetify.

ContactMech, a beautifull component

ContactMech is our first specifics component to demonstrate how to manage ftl replacement in a Vue.Js environment.

With the users, a lot of little details have been enhance or corrected to have a nice and compact presentation.

ContactMech can be used in multiple context, so most party related name have been managed by parameters.
Params are managed in the <screen>, in the <action> section, and if this screen should be included in an other screen it’s possible to overload these parameters.

Currently there are 3 types of parameters :

  • uri to dialog with back-office, get or put informations

  • which contactMechType and which purpose should be show in summary view

  • uiLabel dedicated for this component (they are still some english fixe labels but not for a long time ;-)

There are still some enhancements or functionnalities to add to this component, but now, it’s really usable for the POC about Modular and generic UI

selenium Webdriver

  • a lot of corrections / adaptations after last vuejs update

  • unit test for party portlet, and so more generic methods created by migration from example methods

  • generic test method done for contactMech screenlet