Meilleure pratique pour les noms de variables de module personnalisés?

8

J'ai pris l'habitude de faire des volets de configuration assez robustes pour mes modules maintenant, et je trouve que les noms et la gestion des variables sont assez pénibles .

J'ai des variables comme mymodule_section_subvar_varname_type_contextet non seulement je perds la trace de l'ordre des éléments dans mes noms de variables, mais j'ai l'impression que d'avoir un nom de variable aussi long est un défaut de conception.

J'ai envisagé d'utiliser un tableau sérialisé dans une variable mymodule_section_settingsen conjonction avec un ensemble de fonctions qui facilitent la maintenance de ce tableau, mais j'aimerais avoir des informations sur les meilleures pratiques (le cas échéant) qui ont été établies en dehors des préfixes et / ou des exemples de modules auxquels nous faisons confiance et ce qu'ils font pour de grands ensembles de variables.

Merci!

configuration-management

— electblake
source

De plus, j'aimerais également prendre en compte les mises à jour (c'est pourquoi je penche vers un tableau sérialisé), donc apporter des modifications aux noms des variables ne rend pas les données orphelines et ajouter du travail supplémentaire pour des fonctionnalités / tests de chemin de mise à niveau supplémentaires

— electblake

7

Il est possible d'utiliser une variable Drupal pour contenir un tableau; c'est aussi ce que font les modules de base de Drupal (voir book_type_is_allowed () ).

Il est possible d'utiliser une seule variable Drupal pour contenir différents paramètres utilisés par un module dans un tableau. Avec l' #treeattribut form, il est toujours possible d'utiliser system_settings_form () pour enregistrer le tableau dans une variable Drupal sans écrire de code supplémentaire. La sérialisation de la dé-sérialisation du code est automatiquement effectuée par les fonctions centrales Drupal qui gèrent les variables Drupal (voir le code de variable_set () ).

La question est alors: quand doit-on utiliser une seule variable Drupal pour contenir différents paramètres? J'utiliserais une seule variable pour les paramètres utilisés par une fonction ou un groupe de fonctions; si le tableau contient des valeurs utilisées par (par exemple) 10 fonctions différentes, mais que ces fonctions accèdent à une seule valeur (ou quelques valeurs) à partir de ce tableau, alors je n'utiliserais pas une seule variable persistante pour les paramètres.

— kiamlaluno
source

Savez-vous / quelqu'un sait comment ce type de scénario va réagir dans les fonctionnalités et / ou Strongarm? Je détesterais verrouiller ces modules et les utilisateurs qui chérissent la mobilité que ces modules peuvent apporter.

— electblake

Je ne vois aucune raison pour laquelle les fonctionnalités auraient un problème avec une variable Drupal qui contient un tableau. Quelqu'un d'autre pourrait vous signaler en détail si c'est complètement vrai ou non.

— kiamlaluno

oui, je comprends que cela peut être un peu hors de portée de cette question - mais je veux m'assurer que cette norme fonctionne pour tout le monde :) Je ferai rapport après avoir essayé quelques choses.

— electblake

2

Si un ensemble de paramètres est lié, il est logique de les placer dans un tableau. Par exemple, si vous procédez several variable_getde manière séquentielle. Cela vous donne une certaine flexibilité tout en étant potentiellement un peu plus rapide.

Cependant, cela rendra difficile pour les autres programmes de modifier vos paramètres manuellement via quelque chose comme drush vset ou strongarm. Dans ces cas, les noms de variables longs peuvent être utiles.

— Jeremy French
source