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 clique ». 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’allé retour en 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.