La plateforme Divalto one offre une nouvelle expérience utilisateur. Les principes de bases du développement Diva en mode SaaS sont identiques. Il y a cependant des éléments supplémentaires à fournir pour obtenir l’expérience One
Pour rappel, retrouvez ici
les informations concernant le développement en SaaS Le développement Diva en mode Saas
les informations concernant le développement avec divalto one Comment développer un zoom compatible divalto one
Principe sous Divalto one
La plateforme Divalto one, pour proposer la nouvelle expérience utilisateur, utilise beaucoup d'éléments déjà fournis par un développement et un déploiement SaaS classique. En effet, les mécanismes d'exécution sont identiques pour tous les objets Diva, les fichiers .DHFI (menus par exemple), les impressions et les masques d'écran de l’expérience classique. Seule l’expérience divalto one des zooms nécessite des éléments complémentaires actuellement.
Le principe est le suivant pour un “masque écran zoom”
en expérience classique/OnPremise/Saas, il est composé d’un objet xxx.DHOF unique qui intègre les écrans (WYSIWYG) et les traitements
en expérience one, il est composé
de l’objet xxx.DHOF, le même qu’en expérience classique (pour la bascule au besoin en expérience classique)
d’un objet xxx_t.DHOP qui comporte uniquement les TRAITEMENTS diva de l’objet, pour exécution en expérience one du code de la zone de traitements.
d’un fichier .JSON qui comporte une description du contenu des écrans dans un mode web pour un rendu full web responsive
On voit ainsi la différence : pour fonctionner en expérience one, la plateforme a besoin d’un objet complémentaire et d’un fichier JSON de description de l'écran. Les objets nommés xxx_t.dhop sont indispensable, pensez à bien les prendre !
Lors de la publication d’un zoom vers divalto one, il faudra toujours veiller à ce que les 3 éléments sont déployés en même temps
Si les 3 éléments (DHOF de l'écran, _t.DHOP de l'écran et JSON) ne sont pas déployés en même temps, il y a un risque n’anomalies, par exemple
l'écran de l’expérience classique ne fait pas la même chose que l'écran de l’expérience one
l'écran expérience one fait appel a un traitement qui n’existe pas dans l’objet _t.DHOP
Ce qu’il faut déployer sous divalto one
En complément des résultats habituels de compilation, il est donc nécessaire de déployer sur la plateforme divalto one le binôme : fichier JSON et objet _t.DHOP.
En pratique, la compilation des objets DHOF est combinée avec la construction de fichiers JSON descriptifs des écrans de type ZOOM et des TRAITEMENTS.
RAPPEL : La présence des fichiers, issus de la même compilation que le DHOF, est indispensable pour que les traitements et le rendu écran soient en phase. C’est pourquoi il faut compiler les écrans et déployer les JSON en même temps
Il existe deux manières de déployer ces éléments
Déploiement via XWIN
La méthode la plus simple est d’utiliser XWIN en post-compilation.
En effet, le PROFIL du projet XWin comporte des propriétés du profil de compilation (clic droit + Paramètres sur le nom du profil) et il apparaît un bouton DivaltoOne.
Ce bouton ouvre une fenêtre de paramétrage complémentaire d’XWin spécifique au développement avec la plateforme divalto one.
La compilation des objets n’est pas impactée par ces paramètres complémentaires. Les paramètres servent uniquement à l’envoi automatique vers un serveur cloud
Envoyer le résultat de la compilation vers un serveur DivaltoOne | Coché : envoi par API, en post-compilation, les fichiers JSON issus de la conversion des masques écran vers le serveur One |
URL DivaltoOne | URL de la plateforme DivaltoOne |
Projet | Code du projet One |
Authentification | Code et mot de passe de l'utilisateur ayant accès au serveur et au projet |
Afficher les warning spécifiques à la compilation DivaltoOne |
|
Pour un déploiement via XWIN, on COCHE la case “Envoyer le résultat de la compilation vers un serveur DivaltoOne”. Cela a pour effet de tout compiler et d’envoyer les fichiers JSON à l’issue de la compilation
Les fichiers JSON sont envoyés automatiquement vers le serveur divalto one après une compilation sans erreur. Il faut donc copier les objets par FTP dans les instants qui suivent pour éviter une désynchronisation (telle qu’indiquée au premier chapitre)
Pour bonne pratique, il est recommandé:
de DECOCHER la case “Envoyer le résultat de la compilation vers un serveur DivaltoOne”
de COCHER la case “Afficher les warnings spécifiques à la compilation DivaltoOne”
de faire une compilation complète jusqu'à ce qu’il n’y ait ni erreur ni warning
de vérifier l’emplacement des objets re-compilés en local, et de préparer la liaison FTP (voir les bonnes pratiques Le développement Diva en mode Saas )
de COCHER à nouveau la case “Envoyer le résultat de la compilation vers un serveur DivaltoOne” et finir par une dernière re-compilation qui va envoyer les fichiers JSON vers la plateforme
de copier les objets par FTP dans les instants qui suivent
Déploiement via le Studio
Cette seconde méthode est à préférer si l’on souhaite déployer plusieurs sites en même temps, ou de manière décorrélée de l’action de compilation.
Dans cette seconde méthode, on retrouve tous les éléments indiqués dans le chapitre précédent, à la différence que l’on ne COCHE PAS la case “Envoyer le résultat de la compilation vers un serveur DivaltoOne”. Après une compilation sans erreur ni warning, tous les fichiers sont disponibles sur le poste local (les objets spécifiques, les _t.dhop et les fichiers JSON).
Il est alors possible d’utiliser le STUDIO pour envoyer les fichiers JSON manuellement, et de déposer les objets par FTP.
La seule différence avec le déploiement par XWIN est donc le fait que les fichiers JSON sont envoyés manuellement au lieu d’un envoi automatique. L’utilisation du FTP pour les objets reste identique
Plus d’informations sur l’utilisation du studio : https://divalto.atlassian.net/wiki/spaces/DO1/pages/10848862343/Utilisation+de+Divalto+Studio
ALS : FAIRE UNE CAPTURE DU STUDIO ET DECRIRE COMMENT ON DOIT FAIRE