Development #49204
Mis à jour par Frédéric Péters il y a plus de 2 ans
(description mise à jour pour exposer de manière plus détaillée les interfaces et le plan technique)
Dans Hobo un nouvel écran "Applications", avec des boutons Installer et Créer. (plus tard, un menu kebab, avec une entrée "Catalogues").
h3. Écran de création
Interface avec une petite première section de métadonnées, un nom, une icône, une courte description.
Dans cette interface la liste des types d'objet qui peuvent être intégrés (ça peut être une liste + bouton ajouter comme pour les cellules dans combo), après la sélection d'un type d'objet possibilité de sélectionner l'objet en question (exemple on choisit "Modèles de fiches" puis on peut choisir "Famille").
Lorsque ce choix est fait l'objet est ajouté à la liste des objets de l'application, ainsi que les dépendances de l'objet. (par exemple j'ajoute "Famille" et ça ajoute automatiquement le bloc de champs "Adresse").
Cette étape passe par définir une API qui devrait être similaire entre applications, pour pouvoir :
* lister les types d'objet dispo
* lister les objets d'un type
* récupérer les dépendances d'un objet
Envisager ça comme une API neuve et indépendante, pas s'obliger à exploiter (/api/agendas/ et /api/formdefs/ et autres, qui ne fourniront pas nécessairement toutes les infos souhaitées).
Aparté : dans la liste des types d'objet on pourrait également avoir "données de ces fiches", pour pouvoir dire "prendre les données de la «table» «écoles»). Cela pour dire aussi qu'on peut dévier un peu de ce qu'on considère habituellement comme "objet" et par exemple avoir "hiérarchie de pages" plutôt que des "pages" individuelles.
Quand la même appli est instanciée 2× (cas portail usager / portail agent) les types se retrouvent doublés dans la liste des types d'objets, (ex: "portail usager - page" & "portail agent - page").
On se trouve là avec une liste type :
* wcs / formulaire / signalement (slug)
* wcs / source de données / type-de-signalement (slug) / (dépendance: vrai)
* wcs / modèle de fiche / fiche-d-intervention / (dépendance: vrai)
* authentic / rôle / responsable signalement / (dépendance: vrai)
* combo:portal-agent / page / statistiques-sur-les-signalements
(on peut imaginer cacher les dépendances par défaut, ou les ranger en fin de liste, mais détail).
Sur cet écran, un bouton "Générer" qui va appeler l'API "export" associée à chacun des objets sélectionner, et tout taper dans un .zip qui pourra être télécharger.
Également utile un bouton "Rescanner les dépendances" qui repart des objets qui ne sont pas des dépendances et recalcule toutes celles-ci.
h3. Installation
C'est une boite de dialogue avec un champ fichier et où on peut mettre le zip de l'application. (plus tard ça pourra interroger un ou plusieurs catalogues pour avoir une liste).
Sur validation, il y a découpe du zip et envoi des parties adéquates aux différentes applications.
De manière basique/initiale, ça correspondrait dans chaque application à une API qui serait équivalente à la commande "import_site".
h3. Catalogue
Il devient possible de transformer un Hobo en catalogue, ça pourrait simplement se faire avec un flag "publier dans le catalogue" (et une API qui listerait les applications et un combo qui afficherait ça proprement).
h3. Chronologie
* les API "liste des types d'objet", "liste des objets d'un type", "dépendances d'un objet"
** en les implémentant dans une ou deux applications (typiquement w.c.s. et combo)
* l'écran de création (modèle "Application" et modèle "Élément d'une application").
* l'action "Générer l'application" (i.e. les API d'export)
* l'installation (i.e. le push vers les API "import-site")
* l'extension pas à pas à de nouveaux types d'objet
* l'exposition sous forme de catalogue
* l'évolution dans les modules pour marquer ce qui vient d'une application / n'est pas éditable / etc.
Dans Hobo un nouvel écran "Applications", avec des boutons Installer et Créer. (plus tard, un menu kebab, avec une entrée "Catalogues").
h3. Écran de création
Interface avec une petite première section de métadonnées, un nom, une icône, une courte description.
Dans cette interface la liste des types d'objet qui peuvent être intégrés (ça peut être une liste + bouton ajouter comme pour les cellules dans combo), après la sélection d'un type d'objet possibilité de sélectionner l'objet en question (exemple on choisit "Modèles de fiches" puis on peut choisir "Famille").
Lorsque ce choix est fait l'objet est ajouté à la liste des objets de l'application, ainsi que les dépendances de l'objet. (par exemple j'ajoute "Famille" et ça ajoute automatiquement le bloc de champs "Adresse").
Cette étape passe par définir une API qui devrait être similaire entre applications, pour pouvoir :
* lister les types d'objet dispo
* lister les objets d'un type
* récupérer les dépendances d'un objet
Envisager ça comme une API neuve et indépendante, pas s'obliger à exploiter (/api/agendas/ et /api/formdefs/ et autres, qui ne fourniront pas nécessairement toutes les infos souhaitées).
Aparté : dans la liste des types d'objet on pourrait également avoir "données de ces fiches", pour pouvoir dire "prendre les données de la «table» «écoles»). Cela pour dire aussi qu'on peut dévier un peu de ce qu'on considère habituellement comme "objet" et par exemple avoir "hiérarchie de pages" plutôt que des "pages" individuelles.
Quand la même appli est instanciée 2× (cas portail usager / portail agent) les types se retrouvent doublés dans la liste des types d'objets, (ex: "portail usager - page" & "portail agent - page").
On se trouve là avec une liste type :
* wcs / formulaire / signalement (slug)
* wcs / source de données / type-de-signalement (slug) / (dépendance: vrai)
* wcs / modèle de fiche / fiche-d-intervention / (dépendance: vrai)
* authentic / rôle / responsable signalement / (dépendance: vrai)
* combo:portal-agent / page / statistiques-sur-les-signalements
(on peut imaginer cacher les dépendances par défaut, ou les ranger en fin de liste, mais détail).
Sur cet écran, un bouton "Générer" qui va appeler l'API "export" associée à chacun des objets sélectionner, et tout taper dans un .zip qui pourra être télécharger.
Également utile un bouton "Rescanner les dépendances" qui repart des objets qui ne sont pas des dépendances et recalcule toutes celles-ci.
h3. Installation
C'est une boite de dialogue avec un champ fichier et où on peut mettre le zip de l'application. (plus tard ça pourra interroger un ou plusieurs catalogues pour avoir une liste).
Sur validation, il y a découpe du zip et envoi des parties adéquates aux différentes applications.
De manière basique/initiale, ça correspondrait dans chaque application à une API qui serait équivalente à la commande "import_site".
h3. Catalogue
Il devient possible de transformer un Hobo en catalogue, ça pourrait simplement se faire avec un flag "publier dans le catalogue" (et une API qui listerait les applications et un combo qui afficherait ça proprement).
h3. Chronologie
* les API "liste des types d'objet", "liste des objets d'un type", "dépendances d'un objet"
** en les implémentant dans une ou deux applications (typiquement w.c.s. et combo)
* l'écran de création (modèle "Application" et modèle "Élément d'une application").
* l'action "Générer l'application" (i.e. les API d'export)
* l'installation (i.e. le push vers les API "import-site")
* l'extension pas à pas à de nouveaux types d'objet
* l'exposition sous forme de catalogue
* l'évolution dans les modules pour marquer ce qui vient d'une application / n'est pas éditable / etc.