ProxyEPN

Modifications publiées sur le svn (r346) :

Principe de fonctionnement des listes¶

La plupart des principes des listes administrables en place dans EPNadmin sont conservés :

• les items peuvent disposer d'une description et d'une image en plus de leur libellés
• un champs numérique permet de forcer leur ordre à la présentation des listes
• des listes à plusieurs niveaux sont possibles, chaque item pouvant référencer un item parent
• un champs status permet de retirer/masquer des items sans les supprimer pour autant, assurant la cohérence des données pour des objets les utilisant encore
• un item peut être exclusif à un EPN, permettant la personnalisation des listes
• la création/modification des items sont tracés (auteurs et dates)

Pour améliorer le système, une table est créée en plus de la table des items : elle permet d'y définir les listes, leur accordant une existence même si elles ne disposent d'aucun élément. Celà contribuera à faciliter la gestion des droits (différence entre créer une liste et créer un item). Cette table permet aussi de leur attribuer quelques propriétés :

• titre général de la liste
• status
• mode de gestion des items propre aux EPN (interdit, en supplément ou exclusif ?)
• profondeur maximale autorisée pour la hiérarchie des items

Quelques champs supplémentaires dans la table des items pour améliorer leur gestion :

• depth qui mémorise le niveau de profondeur de l'item, facilement initialisable à sa création (depth du parent + 1), il permettra une manipulation plus aisée des listes arborescentes et du controle de la profondeur max autorisée.
• tag qui pourra avoir deux utilités : soit une alternative courte au libellé (pour présenter des choix multiples de manières synthétique par exemple) ; soit une alternative à l'id (auto-incrément) si on souhaite gérer des références plus "parlante" et plus fixe que l'id numérique.

A noter que le tag utilisé en remplaçant de l'id apporte une différence : ce n'est pas un champs unique. Son utilisation pourra donc être utile avec des items personnalisés (propre à un EPN) qui sauront réutiliser la même "clé" que l'item d'origine qu'ils sont sensés surcharger.

Modification de la base de données¶

Les tables utilisées précédement subissent plusieurs changements :

• suppression de la table inutilisée list_container_link
• création d'une table des listes nommées list_type
• renommage de la table list_container en list_item
• renommage des champs de list_item pour cohérence du nommage
• adaptations / ajouts de certaines colonnes
• recréation des index et clés étrangères
• peuplement de la table list_type

DROP TABLE list_container_link;

ALTER TABLE list_container CHANGE lc_id id INT(11) NOT NULL AUTO_INCREMENT;
ALTER TABLE list_container CHANGE lc_parent_id parent_id INT(11) NULL DEFAULT NULL;
ALTER TABLE list_container CHANGE lc_list_name list_name VARCHAR(25) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '';
ALTER TABLE list_container CHANGE lc_item label VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '';
ALTER TABLE list_container CHANGE lc_description description TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL;
ALTER TABLE list_container CHANGE lc_status status VARCHAR(15) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 'active';
ALTER TABLE list_container CHANGE lc_order rank SMALLINT(5) NOT NULL DEFAULT '10';
ALTER TABLE list_container CHANGE lc_img icon VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '';
ALTER TABLE list_container CHANGE lc_st_id structure_id INT(11) NULL DEFAULT NULL;
ALTER TABLE list_container CHANGE lc_create_date created_at DATETIME NULL DEFAULT NULL;
ALTER TABLE list_container CHANGE lc_update_author updated_by INT(11) NULL DEFAULT NULL;
ALTER TABLE list_container CHANGE lc_create_date created_at DATETIME NULL DEFAULT NULL;
ALTER TABLE list_container CHANGE lc_update_author updated_by INT(11) NULL DEFAULT NULL;
ALTER TABLE list_container DROP lc_options;

UPDATE list_container SET status=1 WHERE status='active';
UPDATE list_container SET status=0 WHERE status='inactive';
UPDATE list_container SET status=-1 WHERE status='hidden';
ALTER TABLE list_container CHANGE status status SMALLINT(15) NOT NULL DEFAULT '1';
ALTER TABLE list_container ADD depth SMALLINT NOT NULL DEFAULT '0' AFTER parent_id;
ALTER TABLE list_container ADD tag VARCHAR(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '' AFTER label;

RENAME TABLE list_container TO list_item;
ALTER TABLE list_item DROP INDEX lc_list_name;
ALTER TABLE list_item DROP INDEX lc_item;
ALTER TABLE list_item DROP INDEX lc_status;
ALTER TABLE list_item DROP INDEX lc_order;
ALTER TABLE list_item ADD INDEX tag (tag);
ALTER TABLE list_item ADD INDEX list_name (list_name);
ALTER TABLE list_item ADD INDEX structure_id (structure_id);
ALTER TABLE list_item ENGINE=InnoDB

CREATE TABLE list_type (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(25) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
    title VARCHAR(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
    description TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL,
    status SMALLINT NOT NULL DEFAULT '1',
    max_depth SMALLINT NOT NULL DEFAULT '1',
    mode SMALLINT NOT NULL DEFAULT '0',
UNIQUE (name)) ENGINE=InnoDB CHARACTER SET utf8 COLLATE utf8_unicode_ci;

INSERT INTO list_type (name) SELECT DISTINCT list_name FROM list_item;

ALTER TABLE list_item ADD FOREIGN KEY (list_name) REFERENCES list_type (name) ON DELETE CASCADE ON UPDATE CASCADE;
ALTER TABLE list_item ADD FOREIGN KEY (structure_id) REFERENCES structure (id) ON DELETE CASCADE;

TODO¶

Si tout est défini sur le papier et a été appliqué sur le schéma de la BdD, l'exploitation de toutes ses fonctionnalités dans le code reste à mettre en place.

Pour le moment, le minimum est assuré avec l'adaptation de la classe myListDB qui permet l'interrogation des listes (récupération de tous les éléments d'une liste ou récupération d'un libellé pour un item donné).

Ainsi l'application reste fonctionnelle, les listes actuelles n'exploitant pas les fonctionnalités évoluées pensées ici. Par contre l'interface permettant leur administration est à refaire avec le framework Symfony.

Modifications publiées sur le svn (r412) :

Ajouts de méthodes pour utiliser les listes avec le tag plutot que l'id :

• ListItemPeer::retrieveByTag($tag, $list_name)
• myListDB::getValuesByTag($name, $all=false)
• myListDB::getValueByTag($name, $tag, $default='')

Le tag pouvant servir pour se substituer à l'id dans l'utilisation des listes, il devient dans ce cas indispensable.
Ainsi une option est ajoutée à la définition des listes pour spécifier si le tag est requis ou non.
(au passage l'autre option 'status' devient aussi une booléenne)

ALTER TABLE list_type ADD tag_required TINYINT(1) NOT NULL DEFAULT '0' AFTER status;
ALTER TABLE list_type CHANGE status status TINYINT(1) NOT NULL DEFAULT '1';

Le fonctionnement de base des listes administrables est en place pour la version 2.0

Les développements doivent continuer pour améliorer l'interface de gestion (ergonomie, actions par lots, etc), ainsi que pour offrir la possibilité à chaque EPN de redéfinir certaines listes à sa guise.