Модульность

Правила раздела: faq.php?mode=okay
Модератор: Модераторы

Чебуратор
Чебуратор
Репутация: 5
Сообщения: 7
Зарегистрирован: 14.03.2021
С нами: 3 года

Сообщение #1 Чебуратор » 14.03.2021, 19:02

Здравствуйте!

Начал разбираться с Модулями в 4.0.2 и возникли вопросы:
(для примера, буду использовать модуль NovaposhtaCost)

1. Можно ли сделать так, что бы поле "volume", переданное из модуля ($this->addBackendBlock('product_variant', 'product_variant_block.tpl');) , хранилось в таблице БД Модуля, а не в __variants?
2. Можно ли организовать его обработку (валидацию, например) в Модуле?

Пока только два часа потратил на изучение так, что простите :)

korshunov
korshunov
Репутация: 146
Сообщения: 1854
Зарегистрирован: 03.12.2015
С нами: 8 лет 3 месяца
Skype

Сообщение #2 korshunov » 15.03.2021, 04:57

1. Можно. Если Вы хотите типовую сравнительно несложную задачу решить непременно самым тяжелым заумным способом...
2. Можно. В этом поле хранится значение, объективно присущее товару. И надо при этом сначала осознать, зачем делать его валидацию, в какие моменты и проч. А пока желание выглядит довольно бессмысленно...

Чебуратор
Чебуратор
Репутация: 5
Сообщения: 7
Зарегистрирован: 14.03.2021
С нами: 3 года

Сообщение #3 Чебуратор » 15.03.2021, 07:59

Блестяще!
Но вот, что действительно бессмысленно, так это Ваш ответ! Какая несложная задача? Нет никакой задачи! Я просто спросил можно ли это сделать "штатными" средствами и если да, то как! Ни каких смыслов искать не нужно!
Зачем вообще Вы потратили время на этот бред (ответ)?

zyxer M
zyxer M
Возраст: 32
Репутация: 77
Сообщения: 419
Зарегистрирован: 03.02.2016
С нами: 8 лет 1 месяц
Откуда: Днепр

Сообщение #4 zyxer » 15.03.2021, 08:35

Чебуратор писал(а):1. Можно ли сделать так, что бы поле "volume", переданное из модуля ($this->addBackendBlock('product_variant', 'product_variant_block.tpl');) , хранилось в таблице БД Модуля, а не в __variants?
вам нужно именно volume перенести или же сделать аналогичное поле? Просто если перенести поле, которое уже модуль добавил, нужно изменять тот модуль. Я распишу на примере нового поля модуля, а вы уже разберетесь.

В init::install() вызываете migrateEntityTable(), чтобы добавить свою таблицу. Затем регистрируетесь addBackendBlock() (название блока можно узнать включив dev_mode https://github.com/OkayCMS/OkayCMS/blob/master/docs/dev_mode.md).
В шортблоке добавляете инпут с именем, которое точно не пересечется с существующим (можно добавлять префикс вендора). Этот инпут будет добавлен в HTML (если ни один шортблок вам не подходит, можно использовать функционал модификации tpl файлов https://github.com/OkayCMS/OkayCMS/blob/master/docs/tpl_modifiers.md)

Затем вам необходимо навесить queue (не chain) экстендер https://github.com/OkayCMS/OkayCMS/blob/master/docs/modules/extenders.md на (скорее всего) Okay\Admin\Helpers\BackendProductsHelper::updateProductsCategories() (тут логика такова что ваш код в ProductAdmin будет отрабатывать после валидации ошибок и добавления/обновления товара http://prntscr.com/10m39q7). В сам класс экстендера необходимо "протянуть" через зависимость Request и EntityFactory. С EntityFactory получить экземпляр вашего Entity (который вы зарегистрировали для работы с этой таблицей) и уже там работать с вашим Entity (логика обновления/добавления записей будет там описана).

Для передачи ваших записей при заходе не страницу товара (чтобы отрисовать уже существующие записи) можно снова queue экстендером расширить Okay\Admin\Helpers\BackendProductsHelper::getProduct(), в котором выбрать существующие для этого товара записи и заасигнить их в дизайн

Если же необходимо как-то валидировать это поле, необходимо уже через Chain расширить метод Okay\Admin\Helpers\BackendValidateHelper::getProductValidateError() и вернуть текст ошибки (перевод ошибки можно получить с класса Okay\Core\BackendTranslations)
Всё сказанное мной, является лично моим мнением, и не является официальной позицией OkayCMS

korshunov
korshunov
Репутация: 146
Сообщения: 1854
Зарегистрирован: 03.12.2015
С нами: 8 лет 3 месяца
Skype

Сообщение #5 korshunov » 15.03.2021, 09:58

Чебуратор писал(а):Блестяще!Я просто спросил можно ли это сделать "штатными" средствами и если да, то как!

Если прочтете свой первый пост повнимательнее, то обнаружите, что спросили Вы несколько иное.
И на Ваши несколько иные вопросы Вам были даны точные ответы: 1. Можно 2. Можно.

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

Чебуратор писал(а):Блестяще!Ни каких смыслов искать не нужно!

Зачастую здесь на форуме, когда расписывают хоть чуть-чуть смысл задачи, находятся варианты решения, о которых спрашивающий вначале и не подозревал. Иногда весьма простые. Но если Вам надо непременно без смысла, а "шоб було", тогда идите своим путем...

Чебуратор
Чебуратор
Репутация: 5
Сообщения: 7
Зарегистрирован: 14.03.2021
С нами: 3 года

Сообщение #6 Чебуратор » 15.03.2021, 15:34

zyxer, Супер! Спасибо! В теории все ясно - буду разбираться дальше:)

Добавлено спустя 4 часа 23 минуты:
zyxer, еще раз Спасибо!
Затем вам необходимо навесить queue (не chain) экстендер https://github.com/OkayCMS/OkayCMS/blob/master/docs/modules/extenders.md на (скорее всего) Okay\Admin\Helpers\BackendProductsHelper::updateProductsCategories()
,
здесь не понял: на этом этапе валидация и add/update product уже прошли? Мы в updateProductsCategories "вваливаемся" (екстендим) для валидации поля?

Чебуратор
Чебуратор
Репутация: 5
Сообщения: 7
Зарегистрирован: 14.03.2021
С нами: 3 года

Сообщение #7 Чебуратор » 17.03.2021, 21:58

korshunov, Ок, спасибо!
Объясню Вам "смыслы": Идея в том, что бы сделать модуль полностью независимый от самой Okay. Модуль который использует Okay как фреймворк, к чему она уже подошла, на мой взгляд (почти). Зачем? Для того, что бы избежать, проблем с развитием самой Окей (надеюсь имена таблиц меняться не будут), и таких же названий полей других модулей.
И да я прекрасно понимаю, что можно называть поля в БД, например, со своим префиксом или вообще иначе и то, что после сотни тыс. записей это будет работать медленнее! Тогда уже будут другие решения!

zyxer M
zyxer M
Возраст: 32
Репутация: 77
Сообщения: 419
Зарегистрирован: 03.02.2016
С нами: 8 лет 1 месяц
Откуда: Днепр

Сообщение #8 zyxer » 18.03.2021, 12:03

Чебуратор писал(а):zyxer, Супер! Спасибо! В теории все ясно - буду разбираться дальше:)


zyxer, еще раз Спасибо!
Затем вам необходимо навесить queue (не chain) экстендер https://github.com/OkayCMS/OkayCMS/blob/master/docs/modules/extenders.md на (скорее всего) Okay\Admin\Helpers\BackendProductsHelper::updateProductsCategories()
,
здесь не понял: на этом этапе валидация и add/update product уже прошли? Мы в updateProductsCategories "вваливаемся" (екстендим) для валидации поля?

да, валидация прошла, она была на этапе Okay\Admin\Helpers\BackendValidateHelper::getProductValidateError(), а во время отработки updateProductsCategories() вы можете в своем экстендере обновлять свои записи
Всё сказанное мной, является лично моим мнением, и не является официальной позицией OkayCMS

korshunov
korshunov
Репутация: 146
Сообщения: 1854
Зарегистрирован: 03.12.2015
С нами: 8 лет 3 месяца
Skype

Сообщение #9 korshunov » 18.03.2021, 12:56

Чебуратор писал(а):korshunov, Ок, спасибо!
Объясню Вам "смыслы": Идея в том, что бы сделать модуль полностью независимый от самой Okay. Модуль который использует Okay как фреймворк, к чему она уже подошла, на мой взгляд (почти). Зачем? Для того, что бы избежать, проблем с развитием самой Окей (надеюсь имена таблиц меняться не будут), и таких же названий полей других модулей.
И да я прекрасно понимаю, что можно называть поля в БД, например, со своим префиксом или вообще иначе и то, что после сотни тыс. записей это будет работать медленнее! Тогда уже будут другие решения!

Звучит интересно, любопытно было бы познакомиться с ментодом и результатами хотя на конкретном простом примере.
1."модуль полностью независимый от самой Okay" и "Модуль который использует Okay как фреймворк" В ПРИНЦИПЕ противоречат друг другу...
2. Дублирование данных - это, как известно, и добавочный расход ресурсов и добавочные риски ошибок.
3. "избежать таких же названий полей других" - в существующей схеме В ПРИНЦИПЕ невозможно. Для этого в общей схеме модульности надо вводить изменения специально под эти цели.
4. "это будет работать медленнее! Тогда уже будут другие решения!" - сознательно создавать трудности, чтобы потом их героически преодолевать - не лучший стиль.

Подозреваю, что изобретаете велосипед. И к тому же реально не очень полезный - много-много работы, чтобы избежать экстремально редкие коллизии...

Чебуратор
Чебуратор
Репутация: 5
Сообщения: 7
Зарегистрирован: 14.03.2021
С нами: 3 года

Сообщение #10 Чебуратор » 20.03.2021, 20:53

Уважаемый,korshunov!
korshunov писал(а):Звучит интересно, любопытно было бы познакомиться с ментодом и результатами хотя на конкретном простом примере.
Я сейчас, конечно фантазирую /но на конкретном примере, не сомневайтесь/, но давайте представим себе ситуацию в которой, я хочу сделать два поля к товару: "Хвост" и "Уши" (длину). При этом мне нужно еще и разделить дуступ: одни "операторы"/администраторы имеют право вносить только "Хвост" а другие только "Уши". И, что, важно, те кто вносит "Уши" не должны видеть (и иметь возможность редактирования) "Хвостов" и наоборот! Но ко всем остальным полям в товаре они должны иметь доступ (редактирование). Фантаааазия! Но сколько же их было на практике! ;)

korshunov писал(а):1."модуль полностью независимый от самой Okay" и "Модуль который использует Okay как фреймворк" В ПРИНЦИПЕ противоречат друг другу...
Нуууу! Я думаю Вы меня поняли! Читать можно так "Модуль который использует Okay как фреймворк, без имплементации в основные модули" )

korshunov писал(а):2. Дублирование данных - это, как известно, и добавочный расход ресурсов и добавочные риски ошибок.
Ни какого дублирования (избыточности) данных я не предлагал - я как раз, хочу их избежать, как и их коллизий. "добавочный расход ресурсов" Join-ы! ну да!

korshunov писал(а):3. "избежать таких же названий полей других" - в существующей схеме В ПРИНЦИПЕ невозможно. Для этого в общей схеме модульности надо вводить изменения специально под эти цели.

Почему? Ну вот есть отдельный Ваш модуль, который хранит данные в своей таблице, вообще от всех независимо - в чем проблема? Но если не там то, вдруг, Вы будете выполнять похожую задачу и в мои "Хвосты/Ухи" своим модулем влезете, которые в __products (в названия полей)? Или я в Ваши? Будет не удобно! :)

korshunov писал(а):4. "это будет работать медленнее! Тогда уже будут другие решения!" - сознательно создавать трудности, чтобы потом их героически преодолевать - не лучший стиль.

korshunov, это маркетинг ;) ! Стандартные решения подходят для многих, но не для всех! У кого 1000000 тыс. товаров - подход _дооолжен_ быть другим! Дело не в стиле ;)

korshunov писал(а):Подозреваю, что изобретаете велосипед. И к тому же реально не очень полезный - много-много работы, чтобы избежать экстремально редкие коллизии...

Нет не велосипед, НО СОГЛАШУСЬ с Вами в плане "избежать экстремально редкие коллизии" - Да! Но максимум не в ущерб скорости, удобства пользователя, и автономности (в смысле дальнейшего развития Okay)

Добавлено спустя 6 минут 49 секунд:
zyxer, Спасибо!

OkayCMS M
Администратор
Аватара
OkayCMS M
Администратор
Репутация: 216
Сообщения: 1627
Зарегистрирован: 12.11.2015
С нами: 8 лет 4 месяца
Сайт Skype

Сообщение #11 OkayCMS » 20.03.2021, 21:05

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

Чебуратор
Чебуратор
Репутация: 5
Сообщения: 7
Зарегистрирован: 14.03.2021
С нами: 3 года

Сообщение #12 Чебуратор » 20.03.2021, 23:14

OkayCMS писал(а):Вопрос.
Если бы был отдельный чатик в месменджерах, чисто для программистов которые делают модули, было бы там общение и было бы там интересно состоять и отвечать на вопросы/ задавать вопросы
Уж простите, но тут я тоже не согласен!
И не просто так, а из-за вашей новой модели бизнеса!
Для вас( OkayCMS ) оставить подобные обсуждения в чате, или, возможно, в отдельную ветку вынести, например "Для разработчиков модулей" (или для "Других придурков" :) ) - просто НЕОБХОДИМО!
Ведь то, что вы уже создали, и как поменяли концепцию... Вам нужно поддерживать тех, кто делает _новые_ модули, а не рассказывать как в шаблоне Smarty, что-то исправить (это конечно тоже нужно!)
Продаваться будут - модули!
Откровенно говоря, документация пока - слабая. А вам еще нужно работать над "ядром" и над "модульностью". Ответы zyxer-а сейчас - лучший manual !
Мое мнение - отдельная ветка!
И желательно, что бы zyxer был главным модератором!

korshunov
korshunov
Репутация: 146
Сообщения: 1854
Зарегистрирован: 03.12.2015
С нами: 8 лет 3 месяца
Skype

Сообщение #13 korshunov » 21.03.2021, 05:26

Чебуратор писал(а):Уважаемый,korshunov!
Я сейчас, конечно фантазирую /но на конкретном примере, не сомневайтесь/, но давайте представим себе ситуацию в которой, я хочу сделать два поля к товару: "Хвост" и "Уши" (длину). При этом мне нужно еще и разделить дуступ: одни "операторы"/администраторы имеют право вносить только "Хвост" а другие только "Уши". И, что, важно, те кто вносит "Уши" не должны видеть (и иметь возможность редактирования) "Хвостов" и наоборот! Но ко всем остальным полям в товаре они должны иметь доступ (редактирование). Фантаааазия! Но сколько же их было на практике! ;)

Приходилось подобное делать. Мой способ такой:
1. у администратора заводится настройка Доступен Хвост
2. у администратора заводится настройка Доступен Уши
3. В зависимости от настроек 1,2 в админке в шаблоне товара показывается или не показывается каждое из двух полей.
4. При сохранении товара учитываются настройки 1,2.

Если без модулей, то работа минимальная. Если модулем, то посложнее, но все типовое.

Вроде бы ничего особо сложного...


Чебуратор писал(а):Почему? Ну вот есть отдельный Ваш модуль, который хранит данные в своей таблице, вообще от всех независимо - в чем проблема? Но если не там то, вдруг, Вы будете выполнять похожую задачу и в мои "Хвосты/Ухи" своим модулем влезете, которые в __products (в названия полей)? Или я в Ваши? Будет не удобно! :)

Проблема в том, что понимать под "своя таблица" и "свое поле". В текущей реализации модульности каждый разработчик может (попытаться) создать новую таблицу или новое поле в существующей таблице. И если у двух модулей совпадут имена таблиц или модулей, то и возникает коллизия, которая наверняка даст ошибки.

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

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

При существующем положении вещей разработчикам модулей можно в названиях своих таблиц и полей добавлять префиксы разработчика и модуля - это практически разрешит вопрос.

По моему, Ваши хотелки можно решить с минимальными трудозатратами...

Добавлено спустя 8 минут 1 секунду:
Чебуратор писал(а):
OkayCMS писал(а):Вопрос.
Если бы был отдельный чатик в месменджерах, чисто для программистов которые делают модули, было бы там общение и было бы там интересно состоять и отвечать на вопросы/ задавать вопросы
Уж простите, но тут я тоже не согласен!
И не просто так, а из-за вашей новой модели бизнеса!
Для вас( OkayCMS ) оставить подобные обсуждения в чате, или, возможно, в отдельную ветку вынести, например "Для разработчиков модулей" (или для "Других придурков" :) ) - просто НЕОБХОДИМО!
Ведь то, что вы уже создали, и как поменяли концепцию... Вам нужно поддерживать тех, кто делает _новые_ модули, а не рассказывать как в шаблоне Smarty, что-то исправить (это конечно тоже нужно!)
Продаваться будут - модули!
Откровенно говоря, документация пока - слабая. А вам еще нужно работать над "ядром" и над "модульностью". Ответы zyxer-а сейчас - лучший manual !
Мое мнение - отдельная ветка!
И желательно, что бы zyxer был главным модератором!

+1
Именно отдельная ветка на форуме - давно назрело.
А "чатик в месменджерах" - это кажется удобным сначала, то потом обычно превращается в помойку, в которой обсуждается сразу 10 вопросов в одной куче и найти уже имеющийся там готовый ответ на свой вопрос весьма тяжело...

OkayCMS M
Администратор
Аватара
OkayCMS M
Администратор
Репутация: 216
Сообщения: 1627
Зарегистрирован: 12.11.2015
С нами: 8 лет 4 месяца
Сайт Skype

Сообщение #14 OkayCMS » 24.03.2021, 09:03

Ок, я информацию принял. Пока отдельную ветку не создаю, так как не уверен что будем продолжать пользоваться этим форумным движком. Но в беклог записал.

korshunov
korshunov
Репутация: 146
Сообщения: 1854
Зарегистрирован: 03.12.2015
С нами: 8 лет 3 месяца
Skype

Сообщение #15 korshunov » 24.03.2021, 09:14

OkayCMS писал(а):Ок, я информацию принял. Пока отдельную ветку не создаю, так как не уверен что будем продолжать пользоваться этим форумным движком. Но в беклог записал.

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


Название раздела: Вопросы по работе с OkayCMS
Правила раздела: faq.php?mode=okay

Быстрый ответ


Введите код в точности так, как вы его видите. Регистр символов не имеет значения.
Код подтверждения

   

Вернуться в «Вопросы по работе с OkayCMS»

Кто сейчас на форуме (по активности за 5 минут)

Сейчас этот раздел просматривают: 30 гостей