Project

General

Profile

Development #58789

évolution disposition édition d'une cellule

Added by Frédéric Péters over 2 years ago. Updated 10 months ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
20 November 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 November 2021 10:40 AM

Related issues

Related to Publik - Development #58847: Améliorations pour la constructions d'applicationsEn cours22 November 2021

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

Actions

History

#1

Updated by Stéphane Laget over 2 years ago

ce serait bien plus pratique en effet

#2

Updated by Pierre Cros over 2 years 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 over 2 years 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 over 2 years ago

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

Updated by Mikaël Ates over 2 years ago

#6

Updated by Lauréline Guérin 10 months ago

  • Status changed from Nouveau to Fermé

je ferme ce ticket, ça a été fait dans #62965

Also available in: Atom PDF