Лучшая практика для имен переменных пользовательских модулей?

8

У меня появилась привычка создавать довольно надежные панели конфигурации для моих модулей, и я считаю, что имена переменных и управление ими - довольно трудная задача .

У меня есть переменные типа, mymodule_section_subvar_varname_type_contextи я не только теряю порядок элементов в именах моих переменных, но я чувствую, что наличие имени переменной, которое является длинным, является недостатком дизайна.

Я рассматривал возможность использования сериализованного массива в переменной mymodule_section_settingsв сочетании с набором функций, которые облегчают поддержку этого массива, но я хотел бы получить некоторую информацию о том, какие (если таковые имеются) лучшие практики были установлены вне префиксов и / или примеры модулей, которым мы доверяем и что они делают для больших наборов переменных.

Спасибо!

configuration-management electblake
источник
Кроме того, я хотел бы также рассмотреть обновления в этом (именно поэтому я склоняюсь к сериализованному массиву), поэтому внесение изменений в имена переменных не лишает данных и добавляет дополнительную работу для дополнительной функциональности / тестов пути обновления
electblake

Ответы:

7

Можно использовать переменную Drupal для хранения массива; это то, что делают основные модули Drupal (см. book_type_is_allowed () ).

Можно использовать одну переменную Drupal для хранения различных настроек, используемых модулем в массиве. С #treeатрибутом формы все еще возможно использовать system_settings_form () для сохранения массива в переменную Drupal без написания дополнительного кода. Сериализация десериализации кода выполняется автоматически основными функциями Drupal, которые обрабатывают переменные Drupal (см. Код variable_set () ).

Тогда возникает вопрос: когда следует использовать одну переменную Drupal для разных настроек? Я бы использовал одну переменную для настроек, которые используются функцией или группой функций; если массив содержит значения, используемые (например) 10 различными функциями, но эти функции обращаются к одному значению (или нескольким значениям) из этого массива, то я не буду использовать одну постоянную переменную для настроек.

киамлалуно
источник
Знаете ли вы / кто-нибудь, как этот тип сценария будет реагировать в рамках функций и / или Strongarm? Я не хотел бы блокировать эти модули и пользователей, которые дорожат мобильностью, которую могут принести эти модули.
Electblake
Я не вижу причин, по которым у Feature могут возникнуть проблемы с переменной Drupal, содержащей массив. Кто-то еще может сообщить вам подробности, если это полностью верно, или нет.
kiamlaluno
да, я понимаю, что это может быть немного за рамками этого вопроса - но хочу убедиться, что этот стандарт работает для всех :) Я сообщу после того, как попробую несколько вещей.
Electblake
2

Если набор настроек связан, то их размещение в массиве имеет смысл. Например, если вы делаете several variable_getэто последовательно. Это дает вам некоторую гибкость, а также может быть немного быстрее.

Однако это затруднит для других программ редактирование ваших настроек вручную с помощью чего-то вроде drush vset или strongarm. В этих случаях длинные имена переменных могут быть полезны.

Джереми Френч
источник