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 va consister à 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és.

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 Drag&Drop 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 cela, il va être 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’autre layout.

Un composant classique ne sera plus directement lié à un écran, mais à un layout.

Un écran ne sera composé que d’un seul et unique layout de base.

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

Voici différents layouts que nous pourrions proposer :

Le principal serait un layout « responsive grid » pouvant donc s’adapter à toutes résolutions et définitions d’écran :

Pour cela, nous devrions utiliser 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 pourrait s’inspirer :

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 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’autre layout seront :

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 (dispo. dans la v4.1) ;
Un layout de type « disposition en frontière » contenant des zones nord, sud, est, ouest et centre (dispo. dans la v4.1) ;
Le « panel splitter » permettant de redimensionner horizontalement ou verticalement plusieurs panneaux : http://demos.telerik.com/kendo-ui/splitter/index ;
Les « onglets » : http://demos.telerik.com/kendo-ui/tabstrip/index ;
Le « panel accordéon » : http://demos.telerik.com/kendo-ui/panelbar/index ;
Un layout de type « formulaire », héritant du responsive grid.

Il possédera une option « Protéger la modification » qui, lorsqu’on détectera qu’un champ a été modifiée, empêchera la fermeture de l’onglet ainsi que le changement d’écran en demandant confirmation. La demande de confirmation sera désactivée si l’utilisateur clique sur le bouton de validation du formulaire n’ayant pas déclenché d’erreurs de validation. La demande de confirmation sera également désactivée si l’utilisateur clique sur le bouton d’annulation du formulaire provoquant une redirection.

Il pourrait permettre, à l’avenir, de mapper la valeur de chaque composant à l’interrieur à un attribut d’une table en base de données ou champ de jeux de données et provoquer le chargement automatique des champs simplement en affectant l’ID de la ligne à modifier à la valeur du layout. La validation de ces champs (requis, doit être un nombre…) serait alors automatique.
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 Drag&Drop devra être complètement revu pour prendre en compte ces éléments.

Il sera directement fait avec le framework OUI et devra donc, au début, être contenu dans une iframe ou dans une page séparée.

Pour cela, il serait 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ée, et pour éviter que l’élément ne « décroche » lorsque le curseur se déplace trop vite.

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

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

4. Éléments à modifier 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 », devra :

Permettre de sélectionner le thème de l’application parmi plusieurs ;

Et permettre leur modification, (type, taille, couleur du texte, couleur de la page, des boutons, de l’entête…), en généralavec aperçu sur l’écran charte graphique. (dispo. en v4.1)

Ultérieurement, permettre par type de composant, ou avec classes personnalisées avec un aperçu à la manière du thème roller de jQuery : http://jqueryui.com/themeroller.

Nous pourrions proposer les différents thèmes Kendo UI qui faudra adapter aux composants PrimeUI.

Le thème par défaut de la plateforme pourrait être basé de Kendo UI, nommé « Default » mais modifié avec les couleurs d’Ontomantics.

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

On pourra ajouter un thème dit « minimal » ressemblant à la V3.

L’écriture de feuille de style CSS manuellement sera toujours permise.

Il faudra aussi supprimer le champ CSS situés sur les écrans, car ils sont rarement utilisés.

Sur les contrôles, il faudrait, en plus du champ CSS générique, ajouter une liste de propriétés comme couleur de fond, couleur, taille du texte, bordure, marges…, comme dans touts autre outils de création d’application. Sur les contrôles complexes, ce champ CSS ne s’applique généralement pas où l’on souhaite. Ce qui rend son utilité discutable…

Les champs « Classe de style » resteront inchangés mais pourraient proposer une auto-complétion.

Une suite d’icônes au format font (vectoriel) devra être proposé pour facilement en ajouter sur nos composants et sera également utilisé 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, sera disponible pour la plupart des composants (menus, boutons, labels, inputs, colonnes des tableaux…) et ces nouvelles icônes seront accessible dans un nouvel onglet du navigateur de ressource de la plateforme.

Quant à la police de caractère à utiliser sur la plateforme, il faudrait utiliser une web font qui serait 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 pourrions utiliser la police par défaut sous Android (depuis Lollipop) (type Arial), nommé :

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 actuelle 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 est plus que nécessaire de repenser cette condition pour 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.

Il pourrait être intéressant que ces conditions soient liées à un objet de type requête qui pourraient toutes être centralisées dans un UC dédié afin d’être réutilisable dans plusieurs règles.

L’utilisation des prepared statements pourrait améliorer les performances lors de boucles d’insertions de l’ordre d’un quart avec PostgreSQL d’après les tests (cf. benchmarks). Les performances seraient, en outre, améliorées lors de l’utilisation de l’opérateur IN avec beaucoup de valeurs notamment avec notre driver LDAP JDBC.

Le débogueur SQL est 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 aurait 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ées et 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é. Un ligne apparaîtra 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 pourront être réimplémentés plus tard pour qu’ils puissent gérer les extensions « GROUPING SETS », « ROLLUP » et « CUBE » tel que définit :

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

Les contrôles tableaux, liste déroulantes… pourraient être indistinctement liés soit à des jeux de données, soit à une « requête ».

Cela permettrait au designer de ne plus avoir à créer systématiquement un nouveau jeu de données pour chaque contrôle avec une règle de chargement.

Dans le cas d’un tableau simple, lié à une requête, la pagination, les filtres et le trie seraient donc être gérés directement par la base (à la manière de phpMyAdmin) et seuls les données visibles seraient requêtées et pourrait l’être après l’affichage de l’écran pour un gain substantiel de performances.

Lier un tableau à une requête pourrait être utile pour définir des listes chaînées qui se rempliraient automatiquement en fonction de la valeur de l’élément parent.

Cette requête liée pourrait également servir pour les layouts « repeat » contenant des listes (lié aux même à des requêtes) mais affichant des éléments différents à chaque ligne.

Pour cela l’onglet « Propriété des colonnes » serait renommé en « Données » ou « Data binding » en anglais et contiendrait le choix du jeu de données ou de l’entité, les propriétés de chaque champ comme actuellement.

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

4.4 Nouveaux tableaux

Le tableau droit actuel souffre de nombreux défauts :

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 champs ce qui rend impossible de masque 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 devra donc être modifié de la façon suivante :

Dans l’arbre de gauche, nous pourrons 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 servira 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 auront des propriétés cellule fusionnable, exportable, filtrable, texte ou agrégat de pied de page, sélection d’un menu contextuel…

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

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

L’onglet « Données » ne servira 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é ou non…

De nouvelles fonctionnalités pourraient être 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) ;
Nouveau type de colonne « statique » avec icônes ou texte qui ne changent jamais servant uniquement pour des colonnes cliquables (dispo. dans la v4.1) ;
Option permettant d’afficher une liste déroulante à choix multiple permettant de choisir quelles colonnes afficher ou masquer (Pouvant être sauvé et restauré grâce au paramètre « Configuration utilisateur » de la table) (dispo. dans la v4.1) ;
Option masquer le titre de la colonne (dispo. dans la v4.1) ;
Propriété permettant de sauvegarder et de restaurer la configuration du tableau au format JSON (dispo. dans la v4.1) ;
Nouveaux filtres déroulant avec sélection multiple (dispo. dans la v4.2) ;
Nouveaux filtres avancés avec menu déroulant proposant en fonction du type de cellule de choisir entre égale, différent, entre, inférieur, supérieur, contiens, contiens pas, et des périodes de dates (hier, aujourd’hui, demain, [la semaine / le mois / l’année] [précédent / courant / prochain])… (dispo. dans la v4.2) ;
Option permettant de réorganiser les colonnes (Pouvant être sauvé et restauré grâce au paramètre « Configuration utilisateur » de la table) (dispo. dans la v4.2) ;
Option permettant de redimensionner les colonnes (Pouvant être sauvé et restauré grâce au paramètre « Configuration utilisateur » de la table) (dispo. dans la v4.2) ;
Possibilité de trier sur plusieurs colonnes en cliquant sur d’autres colonnes en appuyant sur les touches Ctrl ou Shift (dispo. dans la v4.2) ;
Nouveau type de colonne sélection, lorsque la sélection multiple est activée, affichent des checkboxes avec une checkbox trois états permettant de tout sélectionner/désélectionner dans l’entête et sur les lignes de regroupement (dispo. dans la v4.2) ;
Événements au passage en édition, à l’annulation ;
Option cellule éditable ;
Option choix nombre de lignes dans la liste déroulante de la barre de pagination ;
Option table responsive en mode « reflow » ;
Nouveau type de colonne graphique ;
Nouveau type de colonne arbre ;
Nouveau type de colonne fichier avec prévisualisation, lightbox et uplaod si table éditable ;
Nouveau type de colonne ••• « Déclencher le menu contextuel » apparaissant au survol de la ligne déclenchant ;
Option champ de recherche générale ;
Option rafraîchir le tableau ;
Option permettant de déplier/replier un groupe de colonne en choisissant la colonne qui restera affichée (généralement la première) ou plusieurs colonnes qui seront alors fusionnées (Ex : adresse + code postal + ville → adresse complète) ;
Option « défilement infini » ;
Pouvoir définir des types de lignes avec options visibles, style, sélectionnable, menu contextuel différents selon les lignes ;
Option réorganiser les lignes ;

Le tableau croisé devra également être revu :

Dans l’arbre de gauche, nous pourrons créer plusieurs « types de cellules ».
Le jeu de données lié devra alors comporter, en plus des trois champs (ligne, colonne, valeur), un nouveau champ contenant le nom du type (Tout comme le composant arbre actuel).

Pour chacun de ces types, nous aurons un formulaire dans lequel nous pourrons y définir :

Le type de cellule (Date, chaîne de caractère, nombre, image, icône…) ;
Option choix si une cellule est sélectionnable (dans ce cas un événement « Au clique » sera alors ajouté) ;
Option choix d’un menu contextuel différent ;
Option choix de convertisseurs différents ;
Option pour fusionner les cellules dupliquées (Agrégat ou Concaténation).

Le tableau croisé devra, en plus, proposer 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 ;
Option première colonne redimensionnable (dispo. dans la v4.2) ;
Option texte ou agrégat de pied de page (Count, Min, Max, Avg, Sum) ;
Option cellule éditable (dans ce cas un événement « Au changement de valeur » apparaîtra) ;
Option filtrer les autres colonnes ;
Option trier les autres colonnes (multiple ou non) ;
Option champ de recherche générale ;
Option choix nombre de lignes dans la liste déroulante de la barre de pagination ;
Option table responsive en mode « reflow » ;
Option champ de recherche générale ;
Option rafraîchir le tableau ;
Option possibilité de déplier/replier un groupe de colonne soit en choisissant la colonne qui restera affichée (généralement la première) ou plusieurs colonnes qui seront alors aggrégées ;
Option « défilement infini ».

Le planning pourrait égalent être revu pour y insérer des colonnes supplémentaires sur le même principe.

La condition « Pour chaque » doit permettre 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 actuels sont générés coté serveur et sont assez moches.

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

Cette API permettra plusieurs améliorations :

De nouveaux types de graphique tels que Radar, Aire polaire, Bulles ou Doughnut ;
Ajout d’un type mixte mélangeant, ligne, barre et points ;
Des tooltips s’affichent au survol ;
Nombre de séries illimitées via l’utilisation d’une colonne « légende » (dispo. dans la v4.1) ;
Option courbe rectangulaire pour les lignes ;
Réglage du lissage pour les lignes ;
Réglage du remplissage des lignes ;
Option Échelle logarithmique ;
Utiliser automatiquement l’échelle temporelle si colonne label est de type date ;
Option multiaxes ;
Fonctionnalité permettant de récupérer l’image.

Plusieurs extensions ajoutant des types de graphique ou fonctionnalités supplémentaires existent.

Une autre API « vis.js » permettra, en autre, d’avoir des graphiques en 3D sur trois axes.

4.6 Nouveaux composants Upload

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

Un composant « Button d’upload » simple.
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 Droppable permettant de déposer des fichiers depuis le gestionnaire de fichier. Cette zone affichera 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 pourra être lié à un jeu de donnée afin de pouvoir les réafficher.
Un composant « Capture de média » (image, audio et vidéo), adaptés pour les mobiles (dispo. dans la v4.1).

Cette API permettra plusieurs améliorations :

Permettre la sélection de plusieurs fichiers multiples ou d’un dossier entier avec des boutons de sélections ou avec une zone droppable ;
Gestions de plusieurs connexions simultanées pour transférer des gros fichiers en plusieurs morceaux (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é sur leurs extensions, seront filtrés dans la popup de sélection ;
La taille et l’extension des fichiers seront vérifiés avant envoi ;
Le type réel du fichier, basé sur le contenu, sera déterminé coté serveur après avoir reçu le premier et le dernier chunk du fichier. Le téléchargement sera 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 sera affichée pendant les transferts ;
Boutons pour télécharger ou supprimer un fichier pour le composant de type table ;
Faire un composant de capture d’image, audio ou vidéo pour les mobiles (dispo. dans la v4.1) ;
Bloquer la validation tant que l’upload n’est pas terminé (dispo. dans la v4.1) ;
Demander confirmation à la fermeture de la page ou changement d’écran pendant les transferts ;
Afficher le temps restant et la vitesse ;
Option redimensionner les images avant envoi si trop large ;
Compresser les chunks avec l’algorithme LZW avant envoi.

4.7 Révision du composant Carte

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

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

Possibilité de définir plusieurs types d’élément de carte (marqueur, itinéraire, cercle, rectangle, polygone, polyligne…) ;
Le champ « Point de passages » n’existe plus et il faut 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 » 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…
Utilisation du plugin « Leaflet Routing Machine » (licence ISC) permettant de saisir et d’afficher des itinéraires et gère 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ère plusieurs API de géocodage : https://github.com/perliedman/leaflet-control-geocoder ;
Utilisation du plugin « Leaflet MiniMap » (licence 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-moi » : https://github.com/domoritz/leaflet-locatecontrol ;
Utilisation de l’API « Mapbox GL JS » version 1 (licence BSD) permettant d’afficher des tuiles vectorielles : https://github.com/mapbox/mapbox-gl-js/tree/v1.13.0 ;
Possibilité de définir plusieurs types d’élément de carte supplémentaire pour les différentes figures (Cercle, Rectangle, Ligne, Polygone) en plus des marqueurs (dispo. dans la v4.1) ;
Utilisation du plugin « Leaflet Draw » (licence MIT) permettant d’afficher une barre d’outil pour dessiner des figures sur la carte : https://leaflet.github.io/Leaflet.draw/ (dispo. dans la v4.1) ;
Utilisation du plugin « LeafLet MarkerCluster » (licence MIT) pour regrouper les marquer trop proches dans une zone : https://leaflet.github.io/Leaflet.markercluster/example/marker-clustering-realworld.388.htm (dispo. dans la v4.1) ;
Remplacer le plugin de dessin par « Leaflet Geoman » pour pouvoir, entre autre, afficher plusieurs éléments de même type dans la barre à dessin ; (dispo. dans la v4.2) ;
Améliorer la gestion des couches de tuiles avec :

1. Possibilité de définir plusieurs couches de tuiles (de base ou en surimpression) et d’activer un bouton « Couche de tuiles » pour les sélectionner (dispo. dans la v4.1) ;
2. Pouvoir désactiver les overlays ou sélectionner la couche de base avec une propriété « actif » ; (dispo. dans la v4.1) ;
3. Support des layers GeoJSON (dispo. dans la v4.1) ;
4. Support des layers ShapeFile via plugin leaflet (dispo. dans la v4.1) ;
5. Pouvoir ajouter des layers TopoJSON et KML via plugin leaflet ;
6. Prévoir une interface pour choisir un fournisseur payant (Google, MapTiller, MapBox, Here Map, MapKit, Geoportail), entre la clé et générer l’URL ;
7. Prévoir une interface pour choisir un fournisseur gratuit (Défaut : OSM).
  Exemple : https://leaflet-extras.github.io/leaflet-providers/preview/ ;
8. Pouvoir ajouter des layers pouvant contenir les marqueurs et forme géométrique. En sélectionnant le layer dans le type d’élément de carte afin de pouvoir tous les masquer via le bouton des layers ;
9. Prévoir un événement pour capter lorsque le bouton layer est utilisé.

Pouvoir afficher plusieurs itinéraires (dispo. dans la v4.2) ;
Ajout un cache SessionStorage pour les requêtes de géocodage ;
Une meilleure interface de saisie de la position initiale dans le designer ;
Ajout d’une option pour se placer à la position de l’utilisateur dès l’affichage de la carte ;
Choix fournisseur itinéraire parmi OSRMv1, GrapHopper (soit avec clé, soit custom URL), openrouteservice (soit avec clé, soit custom URL), MapBox, Google maps, GeoPortail…

Choix fournisseur de géocodage parmi nominatim, mapbox, Google maps, GeoPortail… avec option pour activer l'autocomlétion pour les champs de recherche d’adresse ;
Le bouton « localisez-moi » doit préremplir le champ de départ ;
Bouton croix sur la barre de recherche ;
Le Bouton flèche pour valider les adresses de départ et d’arrivée ;
Afficher le menu des marqueurs dans une barre de menu de la popup ;
Optimisations pour Mobile et Tablette :

1. Possibilité de tourner la carte en fonction de l’orientation dès que ce sera intégré dans leaflet. Voir : https://github.com/Leaflet/Leaflet/issues/7365
2. Ajout d’un bouton permettant de lancer la navigation native si le point de départ est « Ma position » ;
3. Les boutons sont trop petits.

4.8 Révision de la gestion des exceptions

Il est nécessaire de revoir le fonctionnement des exceptions :

Actuellement, 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.

Il faudrait pouvoir activer un « 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 « en cas d’erreurs » pourra alors être défini en dessous des actions vérifiées et non vérifiées ;

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

Un nouvel éventement « En cas d’erreur » sera disponible au niveau des applications pour capter toutes exceptions non rattrapé y compris celle lors du chargement d’un jeu de donnée en lecture seule ;

Le type comportement d’erreur n’existera 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 pourrions revoir 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 pourrions accéder directement à l’application avec une adresse de type :

http://host/applicationName

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

Un bouton « Connexion » sera 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’affichera dans une fenêtre modale.

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

Nous pourrions 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’affichera directement à l’adresse :

http://host/applicationName

Nous pourrions toujours nous identifier directement avec une adresse de type :

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

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

De plus, les utilisateurs anonymes, qui se connectent sans mot de passe, ne serait plus nécessaire et cette option (qui n’est, dès le départ, qu’une bidouille) pourrait 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.

Nous pourrions revoir la gestion du lien directe de la manière suivante :

Utiliser les 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 » ;
Ne plus utiliser le 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 » ;
Ajouter le 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 ;
Utiliser une quatrième classe « java.time.Duration » pour transporter et manipuler ces durées sur la plateforme ;
Revoir le fonctionnement des opérateurs arithmétiques pour calculer correctement ces objets date et durée et interdire les opérations impossibles ;
Ajouter dans le jeu de donnée un nouveau type de colonne « Durée » qui nécessitera 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 ;
Ajouter un composant « Durée » similaire basé sur le MaskedTextBox.

4.11 Gestion des ID des objets

Actuellement, 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 seront effectués :

Chaque objet de la plateforme (contrôle, comportement, entité, attribut) aura son propre UUID, qui ne changera pas lorsqu’on réimportera un projet sur une autre plateforme.

Ils seront composés du timestamp courant en millisecondes, de l’adresse MAC du serveur et d’un Random sur 32 bits, le tout encodés 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 permettra 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.

Pour les modèles de données, nous les utiliseront 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 seront 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 permettra 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 permettra 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 utilisera les UUID afin de pouvoir affecter des utilisateurs à un groupe ayant été renommé.

Les projets, services métier et fichiers utilisent déjà un système similaire qui sera donc 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

Supprimer toutes les options dépréciées de la plateforme, car in ne servent qu’à complexifier le code.

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

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

Sortir 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 permettra, en outre, d’en rajouter plus facilement notamment pour le cas LDAP Normal où les utilisateurs ne sont pas sauvés dans le référentiel et permettra 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.

Procéder à quelques optimisations :

Remplacer l’opérande « dernier ID inséré par une action d’insertion » par une variable définie directement sur l’action. Cela évitera certains problèmes de duplication d’application, de suppression et de copier/coller.
Fusionner les types d’opérande et les 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 seront donc séparés des variables standard.
Fusionner également les opérandes et les 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.
Stocker pour chaque opérateur et fonction les nombres d’argument min et max qu’il supporte afin de réduire le code nécessaire à ces vérifications.

La variable « ${RESOURCE_PATH} » se référera 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 seront dorénavant inclus dans des projets pour faciliter l’import/export et la copie de projet.

Le contrôle mot de passe devra nativement gérer 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 devra en plus gérer correctement les gestionnaires de mot de passe de Firefox et Chrome en proposant une option pour les bloquer.

Permettre l’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 qui servira lié à un autre contrôle formulaire pour l’accessibilité. On pourra les lier automatiquement lors d’un copier/coller ou lorsqu’on déplacera un input à côté d’un label ou un label à gauche d’un input, il prendra alors le titre de ce dernier.

Des notifications seront disponibles pour les applications. Ils pourront être créés et utilisés de manière similaire aux boîtes de message.

Modifier les 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.

Remplacer le 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/

Remplacer le 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.

Supprimer les 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 #.

Passer les référentiels Oracles 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).

Rendre la classe « Screen » abstraite et créer 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éliorer le 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.

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

Supprimer le support du très obsolète NTLM v1.

Supprimer le 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, stocker les 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 passera plus par le switcher mais directement sur le designer dans lequel un Switcher sera visible en page d’accueil. L’ancien switcher sera 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 ne sera plus possible de les mélanger, car l’option sera 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 devront être réécrit pour prendre en compte toutes ces nouveautés.

Dans les librairies de fonctions :

Permettre d’utiliser les types « File » et « URL » en retour de méthode et modifier toutes les fonctions en conséquences. (Actuellement 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) ;
Permettre l’utilisation de l’interface « AutoCloseable » de Java 7 implémentant la méthode close() pour les librairies de fonctions qui permet le nettoyage et serait 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.
Supprimer également toutes les fonctions dépréciées ;
Ajouter le 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 seront renommées ou revues dans les librairies Math, Date et Crypto….

Nous devrions en profiter 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.

Actuellement, les statistiques des applications sont perdus lors de leur mise à jour de même lorsque les utilisateurs sont supprimés, ils ne doivent plus être marqués comme inconnu.

Changer le 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, rediriger les fichiers hs_err_pid dans le répertoire des logs.

Revoir le système de licence et d’activation :

Ajouter à la clé matérielle 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, n’afficher la popup d’activation que sur la designer uniquement et sur le login mais afficher, à la place, un simple message informant que la plateforme doit être activé et de contacter l’administrateur (Évitera d’avoir à recréer la popup d’activation en OUI pour le moment) ;
Changer l’algorithme de cryptage RSA pour les licences et les activations de la plateforme et régénérer de nouvelles clés plus grandes (avant la livraison au premier client) ;
Réécrire l’application et le web service d’activation en V4 (restera rétrocompatible V3) pour qu’il supporte le nouveau cryptage de la v4 (et migrer le serveur d’activation). Il utilisera la libraire « legacy » pour générer les clés V3 ;