Nouveautés de la version 4.0

Pour la première version stable 4.0 d'Ontomantics, de nombreuses modifications à plusieurs niveaux ont été effectuées, notamment pour corriger un certain nombre de défauts de la plateforme V3 ce qui a conduit à l’incompatibilité avec les anciennes applications.

1. Mise en place du Framework OUI

La première étape a consisté à mettre en place le nouveau framework OUI au niveau du Login, du Switcher et surtout, du Player.

Dans cette première version, le Designer et le débogueur sont restées en ICEfaces 1.8 le temps de stabiliser le framework.

2. Navigateurs supportés pour la version 4.0

L'utilisation de Bootstrap 4 et donc de l’API CSS FlexBoxes impose les versions minimales des navigateurs proposant le support complet de cette API, à savoir Chrome 22, Firefox 28, Internet Explorer 10, Safari 6.1, Edge 12, Opera 12.1 et mobiles iOS Safari 7 et Android Browser 4.4.

Des versions plus anciennes de ces navigateurs (hors Internet Explorer) supportaient déjà une ancienne version de cette spécification, mais n’ont pas été conservés car certaines fonctionnalités étaient alors absentes (flex-wrap, flex-flow, flex-grow, flex-shrink ou align-content).

Les versions de Firefox antérieures à la 33 ne permettent pas de détecter lorsqu’un mot de passe a été rempli automatiquement par le navigateur et ont donc été rejetées.

Les versions minimales retenues pour la version 4.0 sont donc :

• Mozilla Firefox 33

• Google Chrome 22 *

• Opera 15 *

• Microsoft Internet Explorer 10

• Apple Safari 6.1 **

• Microsoft Edge

• Support des navigateurs mobiles à venir **

 * Il y a un bug qui n’affiche pas toutes les icônes Fontawesome avec les versions de Chrome et Opera sous Windows qui n’utilisent pas l’API DirectWrite, à savoir, toutes les versions de ces navigateurs sous XP, Vista ainsi que les versions pour Windows antérieurs à Chrome 37 et Opera 24.

** Nécessite plus amples validations.

3. Positionnement des composants et refonte de l’UC Drag & Drop

Le positionnement des composants dans le Player de la V3 souffre de nombreux défauts :

• Les composants étant positionnées de façon absolue avec des coordonnées X et Y rendent nos applications Web non-responsive et donc, de fait, inutilisable sur les smartphones.

• Il nous est impossible de placer des composants sous des tableaux si l’on ne fixe pas à l’avance la hauteur.

• Si l’on souhaite afficher et masquer dynamiquement des panneaux contenant des composants, il faut alors afficher/masquer tous les composants qu’ils contiennent ainsi que, bien souvent, déplacer les composants situés en dessous.

• Le positionnement précis des composants par Glisser - Déposer fait perdre beaucoup de temps aux designers. (Notamment due à l’absence de réglette permettant de coller ces composants par rapport aux autres comme avec Visual Basic),

• L’élément peut « décrocher » si le curseur se déplace trop vite.

Pour remédier à cela, il a été nécessaire d’introduire la notion de composant de type Layout :

Un layout est un composant qui peut contenir tous types de composants, y compris d’autres layouts.

Un composant classique n'est plus directement lié à un écran, mais à un layout.

Un écran n'est composé que d’un seul et unique layout de base.

Dans le Designer, il est toujours possible de changer de type, le layout de base d’un écran.

Voici différents layouts que nous proposons :

Le principal est un layout Responsive grid pouvant donc s’adapter à toutes résolutions et définitions d’écran :

Pour cela, nous utilisons la librairie Twitter Bootstrap.

Pour Bootstrap, une ligne fait 12 colonnes. L’idée est de définir, pour chaque élément de la grille, le nombre de colonnes qu’ils occupent pour une grande, une moyenne et une petite taille d’écran comme expliqué ici : http://creersonsiteweb.net/page-bootstrap-grille

Bootstrap 4 est désormais basé sur les Flexbox CSS3 (ou Modèle de boîte flexible) pour la gestion des grilles Responsive contrairement à Bootstrap 3 qui lui était basé sur l’instruction CSS float:left. Les flexboxes offre plus de fonctionnalités comme l’alignement vertical, le centrage et surtout la possibilité de spécifier une taille automatique sur certains composants et l’espace restant sera alors partagée entre eux (un système de poids est possible pour le partage) ainsi que la gestion des espaces disponibles, visible à cette adresse :

https://getbootstrap.com/docs/4.0/layout/grid/

Autre exemple d’utilisation des flexBox :

http://www.alsacreations.com/tuto/lire/1493-css3-flexbox-layout-module.html

Voici, par exemple, plusieurs générateurs de page HTML Bootstrap 3 et 4 dont on s’inspire :

http://www.layoutit.com/build, https://bootstrapstudio.io, https://webflow.com/design et http://pingendo.com

Un concurrent propose lui aussi un générateur d’application : https://www.wavemakeronline.com

Un autre concurrent propose lui aussi un générateur d’application Native pour Android et un autre pour iOS: https://thunkable.com/ et la version Open Source dont il est issu nommé MIT AppInventor :

http://appinventor.mit.edu/appinventor-sources/

D’autres layouts sont :

• Le Panel classique dans une version améliorée : http://www.primefaces.org/primeui/#fieldset ;

• Le layout Disposition linéaire, semblable à celui d’Android, permettant simplement d’empiler les composants horizontalement ou verticalement ;

• Le Panel Responsive permettant de définir un panneau latéral (contenant généralement un menu) accompagné, sur les petites résolutions, d’un composant bouton Hamburger pour l’ouvrir et le refermer : http://demos.telerik.com/kendo-ui/responsive-panel/index ;

• Un layout de type Répéter qui permet de répéter des composants grâce à l’utilisation d’un jeu de données (disponible dans la version 4.1) ;

• Un layout de type Disposition en frontière contenant des zones nord, sud, est, ouest et centre (disponible dans la version 4.1) ;

• Un layout Position relative permettant de placer les contrôles avec une position X et Y qui nous sera utile, par la suite, pour importer des applications V3.

La partie création des écrans par Glisser - Déposer a été complètement revue pour prendre en compte ces éléments.

Elle est directement faite avec le framework OUI et doit donc, au début, être contenue dans une iframe ou dans une page séparée.

Pour cela, il est souhaitable d’utiliser, autant que possible, les fonctionnalités de Drag & Drop HTML natif pour simplifier le travail, notamment pour le passage d’un élément vers une iframe, pour l’affichage d’une icône « interdit » aux endroits où l’élément ne peut être lâché, et pour éviter que l’élément ne « décroche » lorsque le curseur se déplace trop vite.

L’utilisation de layouts nous impose également d’afficher un style réagissant au survol des zones droppables (qui peuvent être situés entre deux composants adjacents).

Pendant le déplacement d’un composant existant, le maintien de la touche Ctrl permet de dupliquer un composant existant.

4. Éléments modifiés dans Ontomantics

4.1 Support des thèmes

L’UC Gestion des styles CSS, renommé pour l’occasion en Gérer l’apparence de l’application, permet :

• De sélectionner le thème de l’application parmi plusieurs ;
• Leur modification, (type, taille, couleur du texte, couleur de la page, des boutons, de l’entête…) ;
  
• Ultérieurement, permettre par type de composant, ou avec classes personnalisées avec un aperçu à la manière du Theme Roller de jQuery : http://jqueryui.com/themeroller.

Nous proposons les différents thèmes Kendo UI adaptés aux composants PrimeUI.

Le thème par défaut de la plateforme est basé sur Kendo UI, nommé Default mais modifié avec les couleurs d’Ontomantics.

Les composants ICEfaces du Designer restent inchangés dans cette version 4.0.

Les champs CSS situés sur les écrans ont été supprimés, car ils sont rarement utilisés.

Une suite d’icônes au format Font (vectoriel) devra être proposée pour facilement en ajouter sur nos composants et sera également utilisée pour les composants Javascript (en remplacement des sprites d’images ou autre font spécifique qu’utiliseraient ces composants).

Font Awesome Free (licence SIL OFL 1.1) : https://fontawesome.com/icons (+ Type de fichier + marques)

Il existe également plusieurs alternatives :

Material Design Iconic Font (licence SIL OFL 1.1) : http://zavoloklom.github.io/material-design-iconic-font

Material icons (licence CC BY 4.0) : https://design.google.com/icons/

Ionicons (licence MIT) : http://ionicons.com/

Glyphicons (licence CC BY 3.0) : http://getbootstrap.com/components/#glyphicons (Pas vectoriel)

Un nouveau champ Icône, supportant indistinctement les icônes font et les images, est disponible pour la plupart des composants (menus, boutons, labels, inputs, colonnes des tableaux…) et ces nouvelles icônes sont accessibles dans un nouvel onglet du navigateur de ressource de la plateforme.

Quant à la police de caractère utilisée sur la plateforme, nous utilisons une web font qui est téléchargée par le navigateur, et ceux, afin d’avoir un rendu identique quelque soit le système d’exploitation. La police Thaoma, que l’on utilise actuellement, est indisponible sous Linux, Android…

Nous utilisons la police par défaut sous Android (depuis Lollipop) (type Arial), nommée :

Roboto 2014 (licence Apache) : http://www.fontsquirrel.com/fonts/roboto-2014

Il existe également celle-ci (type Time New Roman) :

Roboto Slab (licence Apache) : http://www.fontsquirrel.com/fonts/roboto-slab

Ainsi que celle-ci (type Monospaced) :

Roboto Mono (licence Apache) : https://fonts.google.com/specimen/Roboto+Mono

4.2 Nouvelle sélection de données

La sélection de donnée en V3 souffre de nombreux défauts :

• Pas de gestion des alias et donc, impossible de requêter plusieurs fois dans la même table ce qui nous oblige à utiliser les vues ;

• Pas de sous-requêtes, d’union et d’intersection ;

• Gestion des ORDER BY avec les jointures complexes ;

• Pas de Limit et d’Offset ;

• Plusieurs conditions nécessaires pour une seule requête ;

• Les GROUP BY sont limitées.

Il était plus que nécessaire de repenser cette condition afin que sa structure soit plus proche de ce qu’il est possible de faire en SQL. De cette façon, il sera plus aisé par la suite, de rajouter d’autres fonctionnalités permises par les différents SGBD.

Ces conditions sont liées à un objet de type Requête et sont toutes centralisées dans un UC dédié afin d’être réutilisables dans plusieurs règles.

L’utilisation des Prepared statements améliore les performances lors de boucles d’insertions de l’ordre d’un quart avec PostgreSQL d’après les tests (cf. benchmarks). Les performances sont, en outre, améliorées par rapport à la V3 lors de l’utilisation de l’opérateur IN avec beaucoup de valeurs notamment avec notre driver LDAP JDBC.

Le débogueur SQL a été revu afin de prendre en compte les types des paramètres et proposer un composant input adapté (Date Picker, Textarea pour les multiples valeurs des IN) et supporte en plus la fonction EXPLAIN pour aider le développeur à identifier des lenteurs.

Il n’y a plus qu’un seul type de valeur retournée et non plus une pour les fonctions et une pour les champs.

Il serait intéressant de supprimer les GROUP BY actuels pour les gérer automatiquement dès la détection d’un agrégat retourné. Une ligne apparaît dans l’arbre de la requête le cas échéant pour avertir le designer que les résultats seront groupés selon toutes les colonnes retournées.

Les GROUP BY ont été réimplémentés pour pouvoir gérer les extensions GROUPING SETS, ROLLUP et CUBE comme défini ici :

https://www.postgresql.org/docs/9.6/static/queries-table-expressions.html#QUERIES-GROUPING-SETS

https://technet.microsoft.com/fr-fr/library/bb522495(v=sql.105).aspx

4.3 Nouvelle colonne Données

L’onglet « Propriété des colonnes » est renommé en « Données » ou « Data binding » en anglais et contient le choix du jeu de données ou de l’entité, les propriétés de chaque champ comme en V3.V3.

L’onglet « Valeurs » pour la saisie des valeurs fixes est également intégré à cet onglet.

4.4 Nouveaux tableaux

Le tableau droit actuel souffre de nombreux défauts en V3 :

• Sa page de propriété des colonnes est devenu trop lourde ;

• Impossibilité d’avoir des champs de type nombre ou dates cliquable, car ces colonnes sont alors triées comme des chaînes de caractères ;

• Impossibilité de fusionner une colonne éditable avec une autre ;

• Impossibilité d’avoir un super titre regroupant plusieurs colonnes ;

• Lorsqu’un menu est défini, c’est le même pour toutes les colonnes du tableau et il n’est pas dynamique ;

• Impossibilité de définir un style sur la colonne éditable ou sur une ligne entière ;

• Impossibilité de désactiver l’édition ou la sélection de certaines lignes en fonction d’une colonne ;

• Impossibilité de désactiver certaines cellules cliquables ;

• Pas d’événement « Au changement de valeur » en mode édition sur les champschamps, ce qui rend impossible de masquemasquer certains champs éditables dynamiquement en fonction d’un autre champ ;

• Impossibilité d’avoir deux colonnes de modification ;

• Impossibilité de sélectionner les colonnes devant toujours ou jamais être exportées ;

• Impossibilité de regrouper verticalement les cellules sur plus d’une colonne ;

• Impossibilité de grouper sur une colonne non visible ;

• Etc.

Le tableau a donc été modifié de la façon suivante :

Dans l’arbre de gauche, nous pouvons créer soit des colonnes simples liées à un jeu de donnés ou une colonne de table, soit une colonne de type éditable, soit un groupe de colonnes composé de plusieurs colonnes.

Le groupe de colonne sert soit à fusionner plusieurs colonnes sous un même titre, soit à afficher un titre au-dessus des titres des colonnes qu’il contient.

Les colonnes simples ont des propriétés celluleCellule fusionnable,fusionnable, exportable,exportable, filtrable,filtrable, texteTexte ou agréAgrégat de pied de page,page, séSélection d’un menu contextuel…contextuel…

Les colonnes simples ont des événements « Au clic » et « Au changement de valeur » si éditable.

En conséquence, les champs de jeux de données n’ont plus de type « lien »Lien ou « lienLien icône » ni d’événement « Au clic ». Ils n’ont également plus de droits. Cela permet d’utiliser une même colonne entre plusieurs tableaux, mais en ayant des événements différents et évite pas mal d’allers-retours entre l’IHM et le modèle opérationnel pour le Designer.Designer.

L’onglet « Données » ne sert plus qu’à sélectionner le jeu de donnée ou la requête et à affecter les propriétés sur les lignes entières comme la classe de style, sélection ou édition activée ou non…

De nouvelles fonctionnalités ont été ajoutées au tableau :

• Possibilité de choisir le type de composant de modification et du filtre ;

• Possibilité de grouper sur une colonne non visible pour la table expansible ;

• Possibilité de sélectionner les colonnes devant toujours ou jamais être exportées ;

• Possibilités de créer plusieurs colonnes modification ;

• Possibilité de grouper sur une colonne non visible pour la table expansible ;

• La pagination peut afficher le nombre de lignes totales et les limite offset de la page courante ;

• Options pour toujours ou jamais exporter une colonne ;

• Option pour figer une colonne à gauche ;

• Option pour limiter le nombre de lignes de texte dans une cellule ;

• Possibilité de regrouper verticalement les cellules de plusieurs colonnes avec possibilité de les hiérarchiser (regrouper en fonction d’une autre colonne groupée) ;

Le tableau croisé a également été revu :

• Dans l’arbre de gauche, il est possible de créer plusieurs « types de cellules ».
• Le jeu de données lié doit alors comporter, en plus des trois champs (ligne,Ligne, colonne,Colonne, valeur)Valeur), un nouveau champ contenant le nom du type (Touttout comme le composant arbre actuel).

Pour chacun de ces types, nous avons un formulaire dans lequel nousil pouvonsest possible de définir :

• Le type de cellule (Date,Date, chaîChaîne de caractère,re, nombre,Nombre, image,Image, icône…Icône…) ;

• Option choixChoix si une cellule est sélectionnable (dans ce cas un événement « Au clic » sera alors ajouté) ;

• Option choixChoix d’un menu contextuel différent ;

• Option choixChoix de convertisseurs différents ;

• Option pour fusionner les cellules dupliquées (Agrégat ou Concaténation)nation).

Le tableau croisé propose de nouvelles options :

• Possibilité de grouper les colonnes ;

• Possibilité de grouper les lignes ;

• Option filtrer la première colonne ;

• Option trier la première colonne ;

• Définir un menu contextuel sur la première colonne ;

• La pagination peut afficher le nombre de lignes totales et les limite offset de la page courante ;
  

La condition « Pour chaque » permet d’itérer en plus sur le sur les lignes sélectionnées d’un jeu de donnée ou les lignes filtrées d’un tableau.

4.5 Nouveaux graphiques

Les graphiques actuelsen V3 sont générés coté serveur et ne sont assezpas moches.très beaux.

Le nouveau composant graphique 2D est basé sur l’API Chart.js, l’une des plus populaires en Open Source qui est rendurendue par le navigateur sous forme de canevas avec animation à l’affichage et à la modification des valeurs.

Cette API permet plusieurs améliorations :

• De nouveaux types de graphiquegraphiques tels que Radar, Aire polaire,polaire, Bulles ou Doughnut ;

• Ajout d’un type mixte mélangeant,langeant ligne,lignes, barrebarres et points ;

• Des tooltipsTooltips s’affichant au survol ;

4.6 Nouveaux composants Upload

Plusieurs nouveaux composants sont basés sur l’API resumable.Resumable.js :

1. Un composant « Button d’upload » simple.

2. Un composant « Table d’upload » évolué affichant une barre d’outils pour sélectionner, démarrer et mettre en pause les chargements ainsi qu’une zone Droppabledroppable permettant de déposer des fichiers depuis le gestionnaire de fichier. Cette zone affiche un tableau des fichiers en cours de transfert ou ceux déjà chargés sur le serveur, avec leurs noms, leur taille, le statut du transfert ainsi qu’une icône ou une miniature des images. Ce composant peut être lié à un jeu de donnée afin de pouvoir les ré-afficher.
   

Cette API permet plusieurs améliorations :

• Permettre la sélection de plusieurs fichiers multiples ou d’un dossier entier avec des boutons de sélectionslection ou avec une zone droppable ;

• Gestions de plusieurs connexions simultanées pour transférer des gros fichiers en plusieurs morceaux (chunks)chunks) ou plusieurs fichiers à la fois ;

• Possibilité de mettre en pause et redémarrer les transferts ;

• Sur les navigateurs compatibles, les type de fichiers, basés sur leurs extensions, seront filtrés dans la popup de sélection ;

• La taille et l’extension des fichiers sont vérifiés avant envoi ;

• Le type réel du fichier, basé sur le contenu, est déterminé coté serveur après avoir reçu le premier et le dernier chunk du fichier. Le téléchargement est alors immédiatement interrompu s’il ne correspond pas aux types autorisés ;

• Vérification du fichier à la fin du chargement par un antivirus si configuré ;

• Une barre de progression est affichée pendant les transferts ;

• Boutons pour télécharger ou supprimer un fichier pour le composant de type tableTable ;

4.7 Révision du composant Carte

Le composant basé sur « Google Maps API v3 » n'est plus disponible dans un premier temps, mais il pourra être réimplémenté ultérieurement.

Le composant basé sur « Leaflet » a été réécrit pour utiliser un certain nombre de plugins existant (afin d’éviter de tous gérer manuellement) et permet plusieurs améliorations :

• Possibilité de définir plusieurs types d’élémentments de carte (marqueur,Marqueur, itinéraire,Itinéraire, cercle,Cercle, rectangle,Rectangle, polygone,Polygone, polyligne…Polyligne, etc.) ;

• Le champ « Point de passages »passage n’existe plus et il faut désormais les définir dans le jeu de données désormais ;

• Le jeu de donnée lié permet de stocker les marqueurs, les itinéraires et les forme géométriques. Une colonne « type »Type permet de sélectionner le type d’élément et une colonne ID du groupe permet de définir plusieurs rectangles, plusieurs polygones, itinéraire…raires…

• Utilisation du plugin « Leaflet Routing Machine » (licence ISC)ISC) permettant de saisir et d’afficher des itinéraires et gèregérant plusieurs API d’itinéraire : http://www.liedman.net/leaflet-routing-machine/ ;

• Utilisation du plugin « Leaflet Control Geocoder » (licence BSD) permettant d’afficher un champ de recherche d’adresse et gèregérant plusieurs API de géocodage : https://github.com/perliedman/leaflet-control-geocoder ;

• Utilisation du plugin « Leaflet MiniMap » (licence BSD)BSD) permettant d’afficher une carte miniature : https://github.com/Norkart/Leaflet-MiniMap ;

• Utilisation du plugin « Leaflet LocateControl » (licence MIT) permettant d’afficher un bouton « localisez-Localisez-moi » : https://github.com/domoritz/leaflet-locatecontrol ;

• Utilisation de l’API « Mapbox GL JS » version 1 (licence BSD)BSD) permettant d’afficher des tuiles vectorielles : https://github.com/mapbox/mapbox-gl-js/tree/v1.13.0 ;
  

4.8 Révision de la gestion des exceptions

Le fonctionnement des exceptions a été retravaillé :

En V3,V3, lorsqu’une exception survient, le comportement courant et les règles qui suivent sont alors interrompus, et un comportement d’erreur est exécuté si défini, puis les comportements qui suivent sont eux exécutés.

Désormais, Il est possible d'activer un « catch »Catch directement sur une règle afin de pouvoir capturer les exceptions et éventuellement y exécuter des actions d’erreur.

Une liste d’action « enEn cas d’erreurs » peut alors être définie en dessous des actions vérifiées et non non-vérifiées.

Dans le cas où une exception est attrapée, l’exécution se poursuit sauf si une action « interrompre »Interrompre est levée dans les actions en cas d’erreurs.

Un nouvel éventement « En cas d’erreur » est disponible au niveau des applications pour capter toute exception non-attrapéee, y compris celle lors du chargement d’un jeu de donnée en lecture seule.

Le type comportementComportement d’erreur n’existe plus, de même que la possibilité d’en sélectionner un sur le formulaire des règles.

4.9 Révision du chemin d'accès aux applications

Nous avons revu la gestion du lien directe de la manière suivante :

Une application aura une option pour spécifier si elle est accessible anonymement.

Si tel est le cas, nous pouvons accéder directement à l’application avec une adresse de type :

http://host/applicationName

L’application s’exécute alors sans aucun rôles ou avec les rôles du groupe défaut.

Un bouton « Connexion » est proposé dans le coin supérieur droit (à la place de « Préférence utilisateur ») ou dans un menu customisé.

En cliquant dessus, le login s’affiche dans une fenêtre modale.

Dans ce cas-là, un nouvel événement au niveau de l’application « À la connexion » est appelé.

Il est possible de forcer l’affichage du panneau login avec les adresses :

http://host/applicationName?login

http://host/applicationName?user=toto

Si l’application n’est pas accessible anonymement, le login s’affiche directement à l’adresse :

http://host/applicationName

Il est toujours possible de s'identifier directement avec une adresse de type :

http://host/applicationName?user=toto&password=toto

Avec un tel fonctionnement, il est nettement plus simple d’accéder à une application anonymement depuis un autre domaine, via un virtualVirtual host,host, et sans iframe comme cela a été nécessaire pour l’application de la DGFiP.DGFiP.

De plus, les utilisateurs anonymes, qui se connectent sans mot de passe, ne sont plus nécessaires et cette option (qui n’est, dès leau départ, qu’une bidouille) peut donc être supprimée. De plus, les clients rechignent parfois à ajouter un compte système à leur annuaire.

4.10 Révision de la gestion des dates et des durées

Un des gros défauts de la V3 concerne la gestion des dates, sur notre fuseau horaire, le timestamp 0 correspond au 1 janvier 1970 à 01:00 du matin ce qui n’est pas sans conséquences :

Si on additionne une date avec une heure, le résultat affichera une heure de retard :
Une date à minuit + 1H00 + 1H00 + 1H00 = minuit.

Pour contrer ce défaut, nous devons systématiquement ajouter au calcul l’expression AddHout(ExtractHout(0)) pour obtenir le résultat correct.

La gestion du lien direct a été retravaillée de la manière suivante :

• Utilisation des classes « java.sql.Date », « java.sql.Time » et « java.sql.Timestamp » pour transporter et manipuler les dates au lieu la simple classe générique « java.util.Date » ;

• Arrêt de l'utilisation du timestamp en millisecondes java lors de la conversion en chaîne de caractère mais utiliser un chaîne de caractère au même format qu’en SQL
  « yyy-MM-dd HH:mm:ss.S » ;

• Ajout du support complet des types SQL « Interval Day to Second » et « Interval Year to Month » dans les modèles de données. Ils sont actuellement supportés par PostgreSQL et Oracle ;

• Utilisation d'une quatrième classe « java.time.Duration » pour transporter et manipuler ces durées sur la plateforme ;

• Amélioration du fonctionnement des opérateurs arithmétiques pour calculer correctement ces objets date et durée et interdire les opérations impossibles ;

• Ajout dans le jeu de donnée d'un nouveau type de colonne « Durée » qui nécessite de spécifier son format, par exemple : « dddd jours hh:mm:ss.S » (Quatre lettres pour afficher le nombre complet, deux lettres pour n’afficher que le restant). Comme pour la fonction « durationToString() » dans les librairies ;
  

4.11 Gestion des ID des objets

En V3, lorsque les contrôles sont rendus dans le Player, ils utilisent leurs ID Hibernate qui a le défaut de changer à chaque import ce qui empêche les tests d’intégration automatisés.

Pour améliorer cela quelques modifications ont été apportées :

Chaque objet de la plateforme (contrôle, comportement, entité, attribut) a désormais son propre UUID, qui ne change pas lorsqu’on réimporte un projet sur une autre plateforme.

Ils sont composés du timestamp courant en millisecondes, de l’adresse MAC du serveur et d’un Random sur 32 bits, le tout encodé en Base64URL pour en réduire leurs tailles à 22 caractères alphanumérique au lieu des 32 caractères hexadécimaux habituellement utilisées.

Pour les contrôles, cela permet de conserver le même ID dans le Player entre chaque plateforme pour simplifier les tests d’intégration automatisés et réduire légèrement la taille des flux due à leur plus petite taille.

Concernant les modèles de données, nous les utilisons pour corriger les problèmes de renommage des tables et des colonnes qui efface des données lorsqu’on met à jour un modèle sur un autre serveur.
Ainsi, ses ID sont déployés en commentaires des tables et des colonnes afin de pouvoir les retrouver facilement même s’ils ont été renommés plusieurs fois.

Pour les rôles, cela permet de réaffecter les droits en cas de mise à jour de projet même s’ils ont été renommés.

Pour les groupes d’utilisateurs, cela permet de réaffecter les permissions en cas de mise à jour même s’ils ont été renommés.

L’assistant d’import/export des groupes utilise désormais les UUID afin de pouvoir affecter des utilisateurs à un groupe ayant été renommé.

Les projets, services métier et fichiers utilisaient déjà un système similaire qui a donc été conservé.

Ces UUID permettront d’avoir ultérieurement un système de gestion de version qui se doit de prendre en charge les renommages d’objets.

4.12 Améliorations diverses

Suppression de toutes les options dépréciées de la plateforme, qui ne servaient qu’à complexifier le code.

Préfixage, dans le référentiel, de toutes les entités correspondant aux actions avec « action ».

Renommage de certaines tables comme « usage » en « behavior », « readSpreadSheet » en « fileImport »…

Sortie de certains paramètres tel que le temps total de connexion, le nombre de lignes dans les tables du designer… de l’entité « user » pour les mettre dans une nouvelle entité « userParameter ». Cela permet, en outre, d’en ajouter plus facilement notamment pour le cas LDAP Normal où les utilisateurs ne sont pas sauvés dans le référentiel, et cela permet d’optimiser le nombre de requêtes LDAP en ne sauvant pas les paramètres dans LDAP à la déconnexion, lorsque l’option est activée, à cause de la sauvegarde du temps total de connexion.

Quelques optimisations :

• Remplacement de l’opérande « dernier ID inséré par une action d’insertion » par une variable définie directement sur l’action. Cela évite certains problèmes de duplication d’application, de suppression et de copier/coller.

• Fusion des types d’opérande et des types de champs de rapport « Variable prédéfinie » avec « Variable » pour diminuer la taille des requêtes Hibernate et permettre l’ajout ultérieur des « variables locales » et des « variables persistantes » avec ajout de champs radio pour sélectionner le type souhaité. Les variables en lecture seule sont donc séparées des variables standard.

• Fusion également des opérandes et des types de champs de rapport « Champ de jeux de données prédéfini » avec « Champ de jeux de données » pour la même raison.

• Stockage pour chaque opérateur et fonction des nombres d’argument min et max qu’ils supportent afin de réduire le code nécessaire à ces vérifications.

La variable « ${RESOURCE_PATH} » se réfère désormais au projet et plus à chaque application. Les images et autres fichiers que contiennent habituellement ces répertoires se trouvent très souvent utilisés par plusieurs applications, services métier du même projet et sont alors dupliqués.

Les modèles de données sont dorénavant inclus dans des projets pour faciliter l’import/export et la copie de projet.

Le contrôle mot de passe gère désormais nativement les cryptages des mots de passe en RSA avec jeton ainsi que le double hachage jusqu’au SHA-512 avec sel pour simplifier et permettre leur utilisation généralisée dans la plateforme pour plus de sécurité. Il gère en plus correctement les gestionnaires de mot de passe de Firefox et Chrome en proposant une option pour les bloquer.

Exécution de plusieurs tâches en parallèle si elles sont dans des planifications différentes.

Ajout d’un contrôle label en plus du composant étiquette lié à un autre contrôle formulaire pour l’accessibilité. Il est possible de les lier automatiquement lors d’un copier/coller ou lorsqu’on déplace un input à côté d’un label ou un label à gauche d’un input, il prend alors le titre de ce dernier.

Des notifications sont disponibles pour les applications. Elles peuvent être créées et utilisées de manière similaire aux boîtes de message.

Modification des champs des rapports pour qu’ils soient liés à des expressions plutôt que directement aux objets variables, champ de jeux de données, contrôles, constantes pour réduire le nombre de tables en base et étendre les possibilités.

Remplacement du pool de connexion par défaut Proxool par HikariCP qui est très performant et activement développé et propose des métriques supplémentaires :

https://brettwooldridge.github.io/HikariCP/

Remplacement du driver JDBC MySQL (licence GPL) par celui de MariaDB (licence LGPL) qui est rétrocompatible et peut également servir à se connecter à des clusters NoSQL Apache Canssandra.

Suppression des vieux Dialects spécifiques aux SGBD n’étant plus supportés par depuis des années : Oracle 8, MySQL 4, PostgreSQL 8.1 ainsi que celui pour le driver Novel LDAP. Le support de SQLServer 2005, PostgreSQL 8.1 et Oracle 8i et 9i n’étant plus assurés par les dernières versions de leurs drivers JDBC respectifs.

Les requêtes des vues peuvent désormais contenir des commentaires -- et #.

Passage des référentiels Oracle en mode d’héritage « TABLE_PER_CLASS » plutôt que « JOINED », comme PostgreSQL, pour simplifier la gestion automatique de mises à jour et largement accélérer les imports au prix d’une légère perte en export (cf. benchmark).

Changement de la classe « Screen » en abstraite et création d'une classe « Page » qui hérite de cette dernière tout comme le fait la classe « DialogBox » pour permettre plus tard l’implémentation d’une classe Fragment.

Amélioration du script de configuration du référentiel en ajoutant le support du passage de paramètres en lignes de commandes (pour les futurs scripts automatisés Ontomantics Express et docker images) et en testant les paramètres et demandant confirmation en cas d’erreur avant d’appliquer les modifications.

Suppression de la condition du rôle pour la remplacer par une variable pour simplifier le code.

Suppression du support du très obsolète NTLM v1.

Suppression du support de MCL V3 (la V4 étant sorti, et de plus, si un autre projet de ce type se présentait, il serait judicieux d’utiliser des lecteurs de code barre tournant sur Android, Windows CE perdant les configurations de temps en temps).

Dans la GED, stockage des fichiers par leur identifiant plutôt que par leur hash afin de simplifier le système.

Lors de l’identification, si l’utilisateur a des droits Admin ou Designer, il ne passe plus par le Switcher mais va directement sur le Designer dans lequel un Switcher est visible en page d’accueil. L’ancien Switcher est maintenu pour les utilisateurs sur smartphones et ceux n’ayant pas les droits Designer et Admin afin d’éviter de charger tous les contrôleurs en mémoire.

Enfin, les connecteurs logiques des conditions (ET et OU) ne fonctionnent pas très bien lorsqu’ils sont mélangés. Il n'est plus possible de les mélanger, car l’option est enregistrée au niveau de la règle dans le référentiel.

L’assistant de création d’écrans dans une moindre mesure, l’assistant de création de méthodes Web et métier et l’assistant d’import de Web services depuis un WSDL existant ont été réécris pour prendre en compte toutes ces nouveautés.

Dans les librairies de fonctions :

• Possibilité d’utiliser les types « File » et « URL » en retour de méthode et modification de toutes les fonctions en conséquences. (En V3, on passe un répertoire de téléchargement temporaire en paramètre de la classe ainsi que l’URL relative correspondante pour que les méthodes créant des fichiers nous retourne cette URL concaténée avec le nom du fichier qu’elles ont créés pour pouvoir le télécharger. Avec ce système, il est donc impossibilité de sauvegarder ce fichier dans la GED) ;

•  Possibilité d’utiliser l’interface « AutoCloseable » de Java 7 implémentant la méthode close() pour les librairies de fonctions qui permet le nettoyage et est appelée automatiquement par la plateforme à la fin de l’exécution de l’événement. Utile pour les librairies créant des fichiers temporaires ou ouvrant des connexions externes que les designers oublient toujours de fermer si une exception survient, entre temps, dans la règle.

• Suppression également de toutes les fonctions dépréciées ;

• Ajout du paramètre « local » dans les fonctions utilisant les jours fériés « isHoliday() », « isWorkDay() », « isWorkableDay() », « numberOfWorkDay() », « numberOfWorkableDay() » pour gérer correctement l’internationalisation.

• Plusieurs fonctions ont été renommées ou revues dans les librairies Math, Date et Crypto….

Nous en avons profité pour passe à des numéros de version sur deux chiffres+révision au lieu de trois comme pour Windows (ex : 10.0.10586) ou le noyau Linux.

En V3, les statistiques des applications sont perdus lors de leur mise à jour de même lorsque les utilisateurs sont supprimés, ils ne sont désormais plus marqués comme inconnus.

Changement du répertoire d’installation par défaut sous Linux/UNIX /usr/local/ontomantics/wildfly en /opt/ontomantics/wildfly car certains clients mettent le /usr en lecture seule par défaut. De plus, par convention, les logiciels n’étant pas installé par les dépôts doivent se mettre dans /opt.

Suppression du support du mode AJP pour les frontaux Apache, car il ne permet pas de récupérer l’IP de l’utilisateur courant, ne fonctionne pas avec les WebSockets et posait d’autres bugs.

En cas de crash de la JVM, redirection des fichiers hs_err_pid vers le répertoire des logs.

Révision du système de licence et d’activation :

• Ajout à la clé matérielle de 3 caractères 0-9A-Z correspondant à un hash sur un seul caractère de chaque élément Adresse Mac, Host et CPU afin que, même en mode hors-ligne, on puisse savoir qu’elle paramètre a été changé ;

• Pour éviter que de simple utilisateurs ne nous envoie des dizaines de mails, nous n'affichons la popup d’activation que sur le Designer uniquement et sur le Login mais afficher, à la place, un simple message informant que la plateforme doit être activée et qu'il faut contacter l’administrateur (Évite d’avoir à recréer la popup d’activation en OUI pour le moment) ;

• Modification de l’algorithme de cryptage RSA pour les licences et les activations de la plateforme et régénération de nouvelles clés plus grandes (avant la livraison au premier client) ;

• Réécriture de l’application et du web service d’activation en V4 (reste rétrocompatible V3) pour qu’il supporte le nouveau cryptage de la v4 (et migrer le serveur d’activation). Il utilise la libraire « Legacy » pour générer les clés V3 ;