Страница 1 из 2

Как понимать модульность

Добавлено: 30.09.2019, 06:44
korshunov
Недавно в теме
viewtopic.php?f=5&t=1464
возник вопрос о том, как надо понимать модульность.

Вот некоторые объяснения из Википедии:
https://ru.wikipedia.org/wiki/Модульность
В1. Модульность — это свойство системы, связанное с возможностью её декомпозиции на ряд внутренне связанных между собой модулей.
https://ru.wikipedia.org/wiki/Модульное_программирование
В2. При разбиении ПС на модули для каждого модуля указывается реализуемая им функциональность, а также связи с другими модулями.
В3. Роль модулей могут играть структуры данных, библиотеки функций, классы, сервисы и др. программные единицы, реализующие некоторую функциональность и предоставляющие интерфейс к ней.

Конечно, сама по себе модульность есть понятие весьма широкое, и здесь надо реально обсуждать не всю его необъятную глубину, а то, как модульность понимается разработчиками Okay и как она конкретно реализована в системе. В связи с этим вопросы:
1. Подходит ли В1 под это понимание? Более точно: версия Okay 3 в целом имеет эту самую декомпозицию или нет? Если да, то как эта декопозиция выглядит - список модулей и связей?
2. Какой набор модулей имеется? Модули - это только то, что в папке \Okay\Modules\OkayCMS - десять штук в 3.0.4, или их больше?
3. Подходит ли В2 под это понимание? Если да, то указывается ли сейчас где-то реально упомянутое в В2? (извиняйте за частые намеки на документацию, но это объективно)
4. Подходит ли В3 под это понимание? Если да, то какие именно программные единицы играют роль модулей в Okay 3 - желательно списочек, хотя бы приблизительный и неполный?

Добавлено: 02.10.2019, 16:07
zyxer
Действительно есть смысл обсудить этот вопрос.

Модуль, в разрезе разговора об модульном OkayCMS это программная единица, выполняющая определенную задачу (можно назвать это доработкой).
Модуль лежит отдельно от основного кода системы, а система в свою очередь, позволяет модулю "вклиниться" в основной поток.
Модуль не обязательно должен быть связан с другими модулями, но может это делать.

Ничего не ясно ))
На примере сравнения со вторым окаем (не модульным). Нам чтобы сделать доработку, нужно добавить код в файлы A, B, C.
Т.е. нужно реально редактировать эти файлы. Проблема в обновлении, когда обновился файл системы, его сложно "накатить" на такой же файл
с модулем. А если в одном месте стоит сразу несколько модулей подряд, еще тяжелее.
+ ставить второй модуль уже тяжелее (т.к. мы обычно ориентируемся на "соседние" строки).
и ещё одна проблема (о ней я писал ранее), это когда выходит обновление системы (пусть плёвое, но "соседние" строки уже изменены),
становится тяжелее устанавливать такой модуль. И сама установка модуля сводится к тому, что нужно отредактировать много фалов и
изменения структуры БД руками.

Мне кажется с этим можно жить, но если есть вариант решить эти проблемы, то чего бы их не решить?

Да, согласен, модульность вносит определенные ограничения, и возможно немного усложняет разработку самого модуля (но это не точно).

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

Также из модуля можно создать свой контроллер со своим дизайном, своими стилями и js-сом (которые объединяться с основным)
и все это хранить в директории модуля. Так же их модуля можно добавлять свои роуты, при этом не редактирую основной файл роутов.
Я думаю суть ясна))

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

Мне кажется я немного внёс ясность в вопрос "что такое модульность в OkayCMS"))

Все текущие модули лежат в директории Okay/Modules/OkayCMS/. Да их не много, они будут пополняться, на второй окай же сейчас много модулей, и на третий будут)). Кстати OkayCMS в пути, это разработчик модулей. Как в композере, идет vendor/package.

Добавлено: 02.10.2019, 16:57
korshunov
Спасибо, объяснения теоретически понятные.

А на практике пока накопилось по меньшей мере 3 вопроса, на которые ответов пока нет.

Q1. А можно ли сделать так, чтобы при установке модуля новой сущности появлялся привычный пункт в обычном меню? Разумеется, средствами самого модуля. Если да, то насколько это легко/сложно?
Q2. А возможно ли в модуле Rozetka сделать в более привычном варианте - чтобы в админке на странице бренда работала галочка 'Выгружать для Rozetka'? Если да, то хорошо бы примерчик рабочий.
Q3. Еще один важный, на мой взгляд, момент по Rozetka. Модуль добавляет новое поле, в частности, в таблицу товаров. Это поле надо обрабатывать в экспорте-импорте. Возможно ли такое средствами самого модуля?

Добавлено: 02.10.2019, 17:46
makki
У меня вопрос как с помощью модуля менять имеющиеся страницы шаблона как админки так и на фронтэнд? Если это невозможно, тогда кажется что большинство модулей не получится устанавливать простой распаковкой модуля в папку Modules/

Добавлено: 03.10.2019, 07:28
zyxer
Q1. А можно ли сделать так, чтобы при установке модуля новой сущности появлялся привычный пункт в обычном меню? Разумеется, средствами самого модуля. Если да, то насколько это легко/сложно?

На данный момент этого нет, но я считаю что это нужно будет сделать. Как это будет выглядеть? вероятнее всего в Init.php модуля, нужно будет прописать что-то типа $this->addBackendMenuItem($menuParams, $itemParams). После реализации будет более ясно как это сделать.

По импорту, пока это не реализовано. Там очень много подводных камней, и нужно всё хорошенько продумать. Чтобы и добавление поля в импорт было не сложным для реализации программистом, и их можно было индивидуально обрабатывать. Нам же нужно не только из колонки csv в колонку БД перенести. Иногда это колонка в csv, а в базе это отдельная таблица (пример категории). Есть мысли как это будет реализовано (и львиная доля уже готова), но всё же, пока рано говорить как этим пользоваться. Но это точно будет.

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

Код: Выделить всё

$this->addBackendBlock('product_variant', 'product_variant_block.tpl');
$this->addBackendBlock('order_contact', 'contact_info.tpl');
"вклиниться" в определённый блок в дизайне.
Чтобы найти блок, в который хотите вставить свой код, нужно включить режим разраба, и в админке появятся такие названия блоков
http://prntscr.com/pe742f, при наведении на него, будет видно его границы. В tpl файле из модуля можно будет юзать переменные как будто этот файл подключили через include.

С фронтом всё немного сложнее. Если админка мы знаем как выглядит и можем её разметить, то с фронтом это перестаёт работать на кастомных шаблонах. Поэтому там сделали механизм типа шорткодов. т.е. модуль может регистрировать свой smarty плагин, и уже плагин всё делает. Но админу во время установки нужно будет заходить в редактирование дизайна и вставлять этот шорткод в нужное место. Решение не идеально, но уже не плохо как по мне. Может кто-то предложит более удобную альтернативу...

Добавлено: 03.10.2019, 08:41
korshunov
Ждем-с.

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

Добавлено: 03.10.2019, 08:47
zyxer
Честно говоря, мне кажется это будет хуже, чем держать его в коде. Это моё мнение.

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

Добавлено: 03.10.2019, 11:44
korshunov
Интересно, чем это хуже?

Сколько сил потратите лично Вы, касается только Вас. А вот сколько потратят потом на доработки другие, работая с Вашим, возможно, чересчур сложным способом, это более существенно...

"сделаю удобный механизм" - куда ж проще, если все будет описываться одной таблицей в БД?

Добавлено: 03.10.2019, 11:59
zyxer
Ну вот как вы себе представляете хранить в одной таблице пункт меню, и его переводы на другие языки (админки) и хранить связки контроллеров, чтобы зайдя в Products и Product был активен тот же пункт меню. Следовательно разработчику нужно точно знать как работает это меню, и что куда записывать.
+ Нужно же где-то держать связку пункта меню (и всех контроллеров которые за ним) с разрешением для менеджера.

А так у нас сейчас есть уже регистрация контроллера (в методе init() модуля) registerBackendController('BackendControllerName'). Вот как вариант, можно добавить к нему ещё параметр, который будет говорить в каком месте меню выводить контроллер.

"чересчур сложного способа" я здесь не вижу. Опять же, могу ошибаться.
Смотрите, чтобы вы понимали как происходит инициализация модуля, это в методе init() класса Okay\Modules\OkayCMS\FAQ\Init\Init нужно вызывать нужные методы, которые будут добавлять модуль в систему в то, или инное место. Этот класс наследуется от Okay\Core\Modules\AbstractInit и вот это и есть часть механизма API, который позволяет модулю "вклиниться" в систему. Методы там имеют phpdoc (не все, но мы это исправим), думаю немного понятны.

Ваша идея, конечно имеет право быть, но можете тогда показать пример реализации этого? Может я вас не совсем правильно понял?

Добавлено: 03.10.2019, 16:27
korshunov
Я имел в виду, что в Okay\Core\ManagerMenu.php имеются строки

/*Массив с меню админ. части (из него автоматически формируется главное меню админки)*/
private $leftMenu = [
'left_catalog' => [
'left_products_title' => ['ProductsAdmin', 'ProductAdmin'],
'left_categories_title' => ['CategoriesAdmin', 'CategoryAdmin'],
'left_brands_title' => ['BrandsAdmin', 'BrandAdmin'],
'left_features_title' => ['FeaturesAdmin', 'FeatureAdmin'],
],
...

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

Добавлено: 03.10.2019, 16:33
zyxer
Верно, но я предлагаю сделать метод (пока как пример) $this->addBackendMenuItem($menuParams, $itemParams), который нужно вызывать в Init(). Вроде сложного ничего. Может это будет немного сложнее, но совсем малость.

Добавлено: 04.10.2019, 06:13
korshunov
Я бы Вам посоветовал, прежде чем кидаться программировать, подумать все же, сравнить два способа и выбрать лучший. Как говорится, семь раз отмерь, один отрежь.

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

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

А приводит такой подход в целом к серьезным недостаткам, на замечания о которых Вы опять-таки не реагируете:
viewtopic.php?p=6765#p6765

Добавлено: 04.10.2019, 07:46
zyxer
Давайте попробуем сравнить.
Способ 1: храним меню в базе.
При заходе в админку, нужно достать его из базы, и на основании этих данных, сформировать массив структуры как сейчас в коде прописан.
Переводы пунктов меню тоже видимо нужно хранить в базе. Причем вариант с ok_lang_backend_menu не подходит, т.к там будут другие языки, не те что в ok_languages. Таким образом стандартный механизм переводов чего либо (товаров, брендов...) не подходит под эту задачу. Можно хранить в базе значение типа "left_products_title", а сам перевод считывать с файлов переводов админки backend/lang/*.php.
Итого (если переводы будем хранить в файлах переводов админки) нужно будет из модуля (в методе install() класса init) вызвать метод $db->query('insert into
ok_backend_menu ...') (кстати метод query не принимает текст запроса, он принимает объект QueryInterface, но можно передать SqlQuery, он предназначен для кастомных запросов). Таким образом добавиться новый пункт меню.

Способ 2: храним в файле.
Всё уже реализовано (имею ввиду хранение меню), нужно написать метод-интерфейс, который будет добавлять новый пункт туда.
Как его вызывать я писал выше.

Итог: по моему мнению ни тот ни другой метод не хуже не лучше. Вы предлагаете просто другой метод. Что я выше написал он что хуже, это просто что нужно переделать меню. Мы от этого ни выиграем ни проиграем. Просто переделаем. Поэтому не вижу смысла его переделывать.

Добавлено: 04.10.2019, 08:37
korshunov
Вы рассуждаете с позиции того, как удобнее разработчику.
А надо бы смотреть поделикатнее, учитывать и эксплуатационные характеристики.

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

1. Можно в запросе сразу учесть права доступа.
2. Формируется полный массив элементов меню, а потом отсекаются те, к которым доступ не разрешен - менее рационально.

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

Добавлено: 04.10.2019, 08:51
zyxer
Вы почему-то это замечать не хотите.
Чего это? я замечаю, и вижу что система действительно немного медленнее стала работать (приблизительно на 0,1-0,2 сек. Более точно отпишусь в соответствующей теме). Поверьте, мы ищем варианты решения этих проблем. Но вариант с разделением переводов на блоки (аля для каждой страницы, я так понял вы это предложили) не лучший вариант. Для экономичности это действительно хорошо, но разработчикам мы создадим Ад (мы подобные варианты уже рассматривали).

1. Для формирования меню надо сделать ОДИН запрос к базе.
2. Для формирования меню сделать, вообще говоря, несколько вызовов Вашей новой функции - по каждому модулю свой вызов. Выходит куда менее экономно.
да это смешно, сравнивать запрос к базе и действие вида (что будет в методе)

Код: Выделить всё

function($menuItem) {
   $this->menu[] = $menuItem;
}


Смешно в плане что обе эти операции займут 0,000000000001 сек и столько же памяти )) Это что касается именно меню.

Ещё, действительно, если есть вариант написать чуть-чуть не оптимальный код, в угоду удобной поддержки, мы скорее всего будем склоняться к варианту удобности.

Добавлено: 04.10.2019, 15:02
korshunov
zyxer писал(а):
Вы почему-то это замечать не хотите.
Чего это? я замечаю, и вижу что система действительно немного медленнее стала работать (приблизительно на 0,1-0,2 сек. Более точно отпишусь в соответствующей теме). Поверьте, мы ищем варианты решения этих проблем.

Очень даже интересно, как Вы подсчитали уровень быстродействия и что значит "на 0,1-0,2 сек." в реальности...

Если каждая страница сайта загружается на 0,1-0,2 сек., то это совсем не "немного медленнее", а для реально активного сайта весьма существенно. А когда модули будут прибавляться, то тормоза могут быстро достигнуть критического уровня...

Добавлено: 05.10.2019, 14:33
Shalm
Врываюсь в ваше обсуждение. Я сейчас правильно понял, что модули от OKAY 2 не подходят к OKAY 3??

Вопрос к поддержке: вы собираетесь адаптировать старые модули (своими силами или тераризируя их разработчиков/владельцев)? Получается что сейчас okay 3 намного урезаней, чем вторая версия. Это крайне важный вопрос. И конечно, интересуют сроки. Я долго ждал 3 версии, чтобы не пришлось переделывать интернет-магазин, а получил недофункциональный продукт, который если и дорабатывать то вручную. Не хотелось бы тратить время и ресурсы на доработку/разработку, которая в последствие не окажется бесполезной.

Добавлено: 05.10.2019, 17:33
korshunov
Вы верно поняли.

В теме
viewtopic.php?f=5&t=1442
сказано:
OkayCMS 3 - это система с полностью переработанным ядром и полностью обновленным программным кодом, поэтому шаблоны и модули с прошлых версий несовместимы.

Для практической работы Вам стоит (продолжать) использовать версию 2. Версия 3, если судить по частоте обновлений, имеет еще массу недостатков. Все удобства модульности, которые тут пропагандируются, реально нужны программистам, точнее тем из них, у кого хватит сил разобраться с немалыми сложностями новой системы. Обычным пользователям версия 3 доставит лишь головную боль и добавочные расходы, особенно если они захотят внедрить новый функционал. Заметьте, в связи с выходом версии 3 стоимость лицензии будет существенно выше.
Еще один момент - нам расписали модульность как большое преимущество, однако появление версии Lite планируется примерно через полгода после основной. Если у них все хорошо и чудесно работает на модулях, почему бы быстренько не убрать из основной версии несколько модулей и не получить Lite?

Пару дней назад получил очередную рассылку с маркетплейса Okay. Сообщают о двух новых модулях, у обоих стоит метка "Совместим только с OkayCMS 2"...

Добавлено: 05.10.2019, 17:43
makki
Я бы сказал наоборот, что модульность больше нужна обычным пользователям, которым будет легко установить в будущем любой модуль и даже обновить версию движка.

Но, на данный момент 2-я версия более освоена программистами, а также шустрее 3-й.

Добавлено: 05.10.2019, 18:41
zyxer
Смотрите, любую доработку можно сделать по прежнему топорно, прямо в коде. Маркетплейс вероятнее всего не будет принимать такие модули. Если смотреть не как на модульный окай, он не так уж и сильно отличается от второго. Но у второго при всем желании небыло возможности создать модуль, который будет отдельным модулем. Можно также топорно (сравнительно легко) перенести доработку со второго окая на третий