Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

Хранение настроек модуля


 Поделиться

Рекомендованные сообщения

Всем привет.

 

Интересует объективное мнение, где лучше хранить настройки модуля.

 

Насколько я понимаю есть 3 варианта:

1) использовать метод add, edit в таблицу oc_module

2) использовать таблицу oc_setting

3) таблица oc_setting совместно со своей таблицей.

 

В 1 пункте мы получаем неприятные подвкладки на общей странице модулей - если вешаем на схему наш модуль.

 

Во 2-ом пункте, мы можем избавится от подвкладок, если повесим на схему наш модуль. Но, в setting и так большой массив гуляет по страницам магазина на фронте.

 

В третьем варианте, получается в setting можно положить ключ например, а в кастомную свою таблицу уже пихать массив настроек.

 

Как лучше делать если условно модуль будет иметь возможность на разные схемы вешать свой массив .....

 

Или модем поделитесь ещё каким то методомо хранением данных модуля.

Ссылка на комментарий
Поделиться на других сайтах


Во всех модулях настройки лучше хранить в setting как заведено в opencart.

Но есть случаи когда настройки в setting хранить не логично.

Расскажу на примере своего модуля выгрузок.

Все настройки модуля сохраняются как и заведено в setting но например настройки замен категорий хранится в своей таблице в виде id, category_id, name и мне удобно с этим работать и при переустановке модуля или обновлении ничего не слетит все будет в отдельной таблице. Также в работе модуля эта таблица джоинится в выборке.

Да, конечно, если данных не много и они не участвуют в выборках (как у меня в модуле при замене категорий) то проще в setting что бы не создавать свою таблицу.

 

Здесь надо смотреть по ситуации конечно и выбрать самый оптимальный вариант с учетом развития модуля и количества данных в нем.

  • +1 1
Ссылка на комментарий
Поделиться на других сайтах

50 минут назад, Exploits сказал:

при переустановке модуля или обновлении ничего не слетит все будет в отдельной таблице.

Кстати не подумал + 1 за отдельную в этом плане.

 

На моем примере, будут кастомный объект js и вторая форма вызов объекта на странице. Отчасти объект может занимать в 5-7 строк кода.

 

Технически будут 2 объекта в массиве. То есть длина будет не более 2.

 

Впринципе своя таблица это +, вдруг пользователь накостоммзирует настройки объекта в форме под себя, то ниче не потеряет 100%.

 

Но из за двух формочек создавать таблицу в бд, сомнительное действие. Другое дело если форм будет с 10+ то вполне оправданно.

 

Сейчас плюс за таблицу пока в сохранении данных.

 

Ссылка на комментарий
Поделиться на других сайтах


Очень абстрактный вопрос.

Смотря какой модуль и где будут использоваться его настройки.

Лучше всего в setting и файловый конфиг для "жестких" установок. В таком случае область видимости ваших настроек расширяется на всю систему, а это практически всегда необходимо.

 

Основной модуль - setting + config

Подмодули - module

Данные модуля, наборы и прочее - отдельные таблицы.

 

В setting храните самые простые данные, в идеале - флаги и числа, ничего особо замедлиться не должно.

 

  • +1 1
Ссылка на комментарий
Поделиться на других сайтах

Очень абстрактный вопрос.
Смотря какой модуль и где будут использоваться его настройки.
Лучше всего в setting и файловый конфиг для "жестких" установок. В таком случае область видимости ваших настроек расширяется на всю систему, а это практически всегда необходимо.
 
Основной модуль - setting + config
Подмодули - module
Данные модуля, наборы и прочее - отдельные таблицы.
 
В setting храните самые простые данные, в идеале - флаги и числа, ничего особо замедлиться не должно.
 
Вопрос.
Если подмодули в oc_module то при установке на схему, в общих модулях отображается его иерархия. Их как то скрыть возможно?

Что бы при хранении подмодулей, в модулях был всегда родитель. Без вложенности детей.

Отправлено с моего ZB631KL через Tapatalk

Ссылка на комментарий
Поделиться на других сайтах


2 минуты назад, pimur сказал:

Что бы при хранении подмодулей, в модулях был всегда родитель. Без вложенности детей.

 

Все зависит от типа модуля

Если это модуль по типу account - то у него нет "детей"

Выдел реализацию модуля, у которого и дети не нужны, а он может сам себя плодить, хотя специфических настроек не имеет


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


 

  • +1 1
Ссылка на комментарий
Поделиться на других сайтах

3 часа назад, chukcha сказал:

Если это модуль по типу account

$this->model_setting_setting->editSetting('account', $this->request->post);

Эт да. Такой только в settings.

Мне просто интересно стало, а можно ли 

if (!isset($this->request->get['module_id'])) {
	$this->model_extension_module->addModule('banner', $this->request->post);
} else {
	$this->model_extension_module->editModule($this->request->get['module_id'], $this->request->post);
}

у данного, обрезать деток =)

 

В моем случае, я пошел по первому варианту, хотя мне более по душе второй из за хранения настроек. Но 

3 часа назад, chukcha сказал:

В сетинг - то что, возможно, будет доступно в магазине...

Заметил, что туда пихают все что не попадя. И по фулл тексту. 

Ссылка на комментарий
Поделиться на других сайтах


Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас
 Поделиться

  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу.
×
×
  • Создать...

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.