Re: [Galette-devel] Présentation et proposition d'interface

[Guillaume AGNIERAY <dev@xxxxxxxxxxxx>]

Le Thu, 3 Oct 2019 12:52:54 +0200
Guillaume AGNIERAY <dev@xxxxxxxxxxxx> a écrit :

> Le Thu, 03 Oct 2019 08:07:23 +0200
> Johan Cwiklinski <johan@xxxxxxxx> a écrit :
> 
> > Globalement, penses que les plugins peuvent ajouter des entrées à 
> > certains endroits ; maps et paypal mettent le menu du haut de
> > travers assez efficacement :D  
> 
> Je me doutais que les plugins se comporteraient mal au niveau de ce
> menu, et c'est prévu que je me penche sur leur cas maintenant avant
> d'avancer plus sur les autres templates ;)

Je viens de jeter un œil et je m'attendais à pire :)

Pour le moment je n'ai regardé que les 2 modules que tu cites.

Le problème sur le menu du haut est en fait très simple à régler : par
un simple changement de classes sur les liens dans le template du menu
public des plugins.

Dans mes modifs, les menus sont aussi "dupliqués" dans le menu en
sidebar sur mobile et tablette. Là, c'est un peu moins trivial.

Pour le menu public, le problème engendré dans ce cas peut déjà se
régler grâce à la méthode getPublicMenus() telle qu'elle existe. 

La modif nécessaire est faite sur ma branche, et j'ai mis en PJ des
patchs pour les 2 modules.

Pour le second type de menu inclus pour les plugins, d'une part la
fonction est différente et ne permet pas de choisir d'ajouter un
conteneur aux liens ou pas. D'autre part, ça nécessite de réécrire tout
le menu en accordéon (ce qui ne pose absolument aucun souci, puisque
c'est déjà ce que j'ai fait dans mes expérimentations sur
feature/twig-semantic). Enfin ça nécessitera de réécrire la structure
HTML dans le template du plugin en conséquence.

Je ferai sinon des includes pour les différents menus (haut, gauche,
sidebar mobile) ce sera plus simple à gérer.


> Le tout est de savoir si ce menu est réellement indispensable à cette
> position. Sinon il faut voir les différents cas de figure mais je ne
> pense pas que ce soit un problème insurmontable si on le garde.

Ma réflexion est la suivante : le problème du menu du haut tel que je
l'ai fait à ce stade (en ligne sans menus déroulants), et tel que sont
conçus les menus des plugins, c'est comment y afficher tous les liens
correctement lorsque plusieurs plugins sont activés ?

La solution immédiate serait de faire un menu déroulant pour toutes les
pages publiques. Et pourquoi pas seulement à partir du moment où elles
dépassent un certain nombre ? (mais pour aller jusque là il faudrait
une méthode qui renvoie une liste de toutes les entrées déclarées par
l'ensemble des plugins pour pouvoir la parcourir dans le template).

On peut aussi imaginer une présentation plus condensée avec juste les
icones visible et le label qui se découvre avec une petite transition au
survol (exactement comme le fait nextcloud pour ses applications :
https://nextcloud.com)

Et puis, on pourrait aussi ajouter les autres menus des plugins dans ce
menu en haut de page, sous forme de menus déroulants supplémentaires. 

Et si un jour on se retrouve avec plusieurs dizaines d'entrées dans ce
menu, on peut imaginer n'afficher en ligne que les X premières entrées
et placer les autres dans un menu déroulant à la fin.

Ou aussi, on peut imaginer un type de menu supplémentaire, qui,
lorsqu'un plugin en ferait usage, prendrait la place des entrées
normalement visibles à cet endroit (tout en les laissant accessibles en
les déplaçant par exemple dans une liste déroulante).

Tout ça suppose donc idéalement de pouvoir passer des variables aux
templates des menus lorsqu'ils sont inclus avec les méthodes dédiées.

Bref, le choix des possibilités est vaste. Et avant d'en arriver
jusqu'aux cas extrêmes imaginés, je pense qu'on pourra trouver une
solution assez simple :)
-- 

Guillaume AGNIERAY