Project

General

Profile

Development #58789

évolution disposition édition d'une cellule

Added by Frédéric Péters 7 months ago. Updated 7 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
20 Nov 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

On a aujourd'hui des éléments directement dans la cellule directement dépliée et d'autres derrière des popups, ça amène des moments de perte de données quand on modifie certains paramètres dans une popup sans avoir explicitement enregistrés ceux directement dans la cellule (c'est par exemple #9429). Aussi les liens en bas de cellule reprennent à la fois des bouts de paramétrage (options, visibilité, ressources), des actions (dupliquer/supprimer) et de l'ui ("fermer" qui ferme l'édition de la cellule).

À discuter de ça on arrive à l'idée d'uniformiser via un système d'onglets, on n'a aujourd'hui pas ça dans gadjo, il y a à réfléchir un peu à la forme. Pour les actions ça matche assez le modifier/dupliquer/supprimer des champs dans w.c.s., ça pourrait être repris pareil, modulo que "modifier" serait l'ouverture de la zone d'édition (plutôt qu'une lien vers une page distincte).

Illustration très rapide en pièce jointe. (qui montre aussi qu'il y aura par la suite un temps de rangement des paramètres, ceux qu'on veut faire apparaitre tout de suite, et ceux qu'on préférera reléguer dans un onglet).

(attention pour certaines cellules il y a des actions supplémentaires qui font des rechargements de page, comme l'ajout d'une couche carto, il faudra aussi les attraper pour que ça enregistre/rafraichisse la cellule, éventuellement dans un second temps).


Files

capture-cell.png (30 KB) capture-cell.png Frédéric Péters, 20 Nov 2021 10:40 AM

Related issues

Related to Publik - Development #58847: Améliorations pour la constructions d'applicationsNouveau22 Nov 2021

Actions
Related to Publik - Development #49208: Fluidité / animation des interfaces backofficeNouveau08 Dec 2020

Actions

History

#1

Updated by Stéphane Laget 7 months ago

ce serait bien plus pratique en effet

#2

Updated by Pierre Cros 7 months ago

De mon côté comme j'aime bien privilégier l'unité des interfaces d'une brique à l'autre (gros gain en matière d'apprentissage), j'aurais plutôt envie d'avoir, comme pour les champs w.c.s., tous les éléments qui sont dans des onglets sur la capture, regroupés derrière un "Paramètres supplémentaires" replié par défaut (avec le même comportement, le truc apparaît dans l'interface basique si il est utilisé).

L'alternative étant de mettre des onglets côté w.c.s. aussi :-)

#3

Updated by Frédéric Péters 7 months ago

Oui je pense qu'il y aurait aussi à catégoriser davantage les paramètres dans w.c.s., on emploie des titres dans l'action webservice ("requête", "réponse", "gestion des erreurs"), qui pourraient être autant d'onglets. (et je ne suis plus fan du comportement de sortir des bouts de "avancé" dans w.c.s. depuis longtemps, voir par exemple #25602)

#4

Updated by Mikaël Ates 7 months ago

  • Related to Development #58847: Améliorations pour la constructions d'applications added
#5

Updated by Mikaël Ates 7 months ago

Also available in: Atom PDF