Considérations préalables

Si nous limitons l'a notion de sous-catégorie à l'affichage public sous forme arborencente la liste des catégories. Nous simplifions le problème en excluant volontairement toutes notions de sous-catgories lors des affichages dans la partie administration.

Nous limitons volontairement, les ajouts ou modifications au codes d'origine.

Mode opératoire

  • il faut stocker dans la table dc_categorie ou dans une table liée l'information catégorie_parent
  • lors de l'utilisation pour la génération de la liste le principe est de générarer des listes imbriquées
[xml]
  • catégorie 1
  • catégorie 2
    • sous-categorie21
    • sous-categorie21

Et la commence les problèmes car chacun voit midi à sa porte.

  • soit on considère qu'il faut systèmatiquement générer une liste compléte (c.a.d. toutes les catégories définies )
  • soit on considère qu'il faut systèmatiquement générer une liste des catégories remplies (c.a.d. toutes les catégories définies non vide ou parentes d'une sous catégorie non vide).
  • soit on considère qu'il faut générer une liste des catégorie et ne mentionner que les sous-catégorie voisine. (pour reprendre l'exemple aucune sous-catégorie n'est visible lorsqu'on est dans la catègorie 1).

Pour faciliter la gestion de l'affichage on peut définir des classes CSS et utiliser l'attribut display pour faire apparaire ou disparaitre les sous-menus.

Bien entendu ces fonctionnements peuvent être perturbés par la presence du plugin multi-catégorie.

Pour réaliser la liste on peut soit utiliser une requete recursive (pas terible en termes de performance), soit utiliser des requetes imbriquées (pas terible en termes de performance).

Un autre problème à régler, c'est d'intégrer tout ça à l'interface d'administration. Sous forme de plugin cela sous entend (à défaut de callback) qu'il existe un ecran où l'on peut modifier les catégories et leur ordre, et un autre pour gerer leur imbriquation (c'est pas simple pour l'utilisateur).