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

[pimur]

Всем привет.

 

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

 

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

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

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

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

 

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

 

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

 

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

 

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

 

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

[Exploits]

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

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

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

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

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

 

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

[pimur]

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

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

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

 

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

 

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

 

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

 

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

 

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

 

[SooR]

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

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

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

 

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

Подмодули - module

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

 

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

 

[pimur]

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

Вопрос.
Если подмодули в oc_module то при установке на схему, в общих модулях отображается его иерархия. Их как то скрыть возможно?

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

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

[chukcha]

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

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

 

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

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

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


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


 

[pimur]

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 сказал:

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

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