Jump to content

Recommended Posts

Всем привет.

 

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

 

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

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

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

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

 

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

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

  • +1 1

Share this post


Link to post
Share on other sites
50 минут назад, Exploits сказал:

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

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

 

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

 

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

 

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

 

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

 

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

 

Share this post


Link to post
Share on other sites

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

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

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

 

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

Подмодули - module

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

 

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

 

  • +1 1

Share this post


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

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

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

Share this post


Link to post
Share on other sites
2 минуты назад, pimur сказал:

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

 

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

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

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


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


 

  • +1 1

Share this post


Link to post
Share on other sites
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 сказал:

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
You are posting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.