Для начала предлагаю определиться с терминологией.
Пользователь - человек который пришел на сайт что-то купить (уже на конечном ИМ)
Админ - человек, который (тот же пользователь) работает еще и в админ-панеле сайта.
Разработчик - собственно сам программист.
Кнопки и поля в БД может добавлять только разработчик. Будь то модуль или доработка прямо в системе.
Это будет в документации, но вам постараюсь кратко описать.
Чтобы добавить поле, к любой существующей сущности (которые лежат в Okay\Entities) нужно (на примере бренда, BrandsEntity):
Не ленговое поле:
Добавить поле в таблицу, указанную в свойстве $table нашего класса, это "ok_brands" (с указанием нужных типа, длины и т.д.).
Добавить название этого поля как элемент массива в свойство $fields нашего класса.
Ленговое поле:
Добавить поле в таблицу, указанную в свойстве $table нашего класса, это "ok_brands" (с указанием нужных типа, длины и т.д.).
Добавить поле в таблицу, указанную в свойстве $langTable (там название пишется без приставки "ok_lang_") нашего класса,
нашем случае это "brands", следовательно нужно изменять таблицу "ok_lang_brands" (с указанием нужных типа, длины и т.д.).
Тип поля ленговой таблицы и основной, должны совпадать.
Добавить название этого поля как элемент массива в свойство $langFields нашего класса.
Если при вызове метода get() или find() (в контроллере) не был указан набор полей, которые нужно достать, это поле будет доставаться по умолчанию.
Можно использовать это поле (думаю не нужно описывать как)
Это что касается добавления поля НЕ через модуль.
Чтобы добавить поле к сущности через модуль это будет уже в документации. Там кратко тяжело описать.
Но можете посмотреть на примере уже существующего модуля выгрузки в розетку, там добавляются поля к категории, бренду, товарам.
Добавляются они в Okay\Modules\OkayCMS\Rozetka\Init\Init в методе init().
Я уже просил в теме привести хотя бы один примерчик того, как новосозданная модульность помогает облегчить работу по изменениям в системе. Пока "разработчики быстрого реагирования" спустя два дня еще не удосужились хоть что-то ответить.
Подниму вопрос еще раз: нельзя ли на примере обсуждаемого вопроса продемонстрировать преимущества модульности - дать решение, чтобы отдельный пользователь мог быстренько эту кнопку выгрузки поставить. Чтобы не было неуклюжих глуповатых отмазок типа "я это редко встречал", "это мало кому нужно". Народ тут вполне понимающий, способен самостоятельно без подсказок решить, что кому нужно. А вот разработчикам надо только давать возможности более гибко...
По нашей терминологии кнопку ставить может не пользователь, а админ. Но он может установить модуль, который предварительно сделал разработчик.
Админу чтобы установить модуль (если его разработчик корректно оформил) нужно по FTP загрузить файлы модуля в директорию Modules/<Vendor>/<ModuleName>/
Затем зайти в админ-панеле в раздел модули, и напротив нового модуля нажать кнопку "установить". И все, админ за пару минут установил модуль.
В чём преимущество, так это если ранее мы делали модуль, который нужно вставлять между строк "ААА" и "БББ",
затем в окае выходит совсем плёвое обновление, где строка "ААА" изменилась и выглядит как "ввААА".
Код остался обратно совместимым с модулем, но сама строка, которая была ориентиром для установки модуля изменилась,
у многих админов (а иногда и разработчиков) это вызывало затруднения, и модуль нужно было снова обновлять.
Сейчас же такая проблема должна уйти, т.к. весь модуль лежит в отдельной директории и использует системные ресурсы (правда это накладывает определённые ограничения).
Из модуля можно будет добавлять поля и добавлять новые таблицы в БД. Не влазя в саму базу (через PMA или adminer...).
Пример, опять же, посмотрите на модуль выгрузки в розетку, или любой другой модуль в текущем окае, там видно что доработка была реализована только с помощью модульной системы, и код не разбросан по ядру.
P.S. Рекомендую работать в третьем окае в PHPStorm, отличная IDE, и для неё (чаще всего) в коде стоят аннотации, чтобы он понимал экземпляр какого класса лежит в данной переменной.
Для начала предлагаю определиться с терминологией.
Пользователь - человек который пришел на сайт что-то купить (уже на конечном ИМ)
Админ - человек, который (тот же пользователь) работает еще и в админ-панеле сайта.
Разработчик - собственно сам программист.
Кнопки и поля в БД может добавлять только разработчик. Будь то модуль или доработка прямо в системе.
Это будет в документации, но вам постараюсь кратко описать.
Чтобы добавить поле, к любой существующей сущности (которые лежат в Okay\Entities) нужно (на примере бренда, BrandsEntity):
Не ленговое поле:
Добавить поле в таблицу, указанную в свойстве $table нашего класса, это "ok_brands" (с указанием нужных типа, длины и т.д.).
Добавить название этого поля как элемент массива в свойство $fields нашего класса.
Ленговое поле:
Добавить поле в таблицу, указанную в свойстве $table нашего класса, это "ok_brands" (с указанием нужных типа, длины и т.д.).
Добавить поле в таблицу, указанную в свойстве $langTable (там название пишется без приставки "ok_lang_") нашего класса,
нашем случае это "brands", следовательно нужно изменять таблицу "ok_lang_brands" (с указанием нужных типа, длины и т.д.).
Тип поля ленговой таблицы и основной, должны совпадать.
Добавить название этого поля как элемент массива в свойство $langFields нашего класса.
Если при вызове метода get() или find() (в контроллере) не был указан набор полей, которые нужно достать, это поле будет доставаться по умолчанию.
Можно использовать это поле (думаю не нужно описывать как)
Это что касается добавления поля НЕ через модуль.
Чтобы добавить поле к сущности через модуль это будет уже в документации. Там кратко тяжело описать.
Но можете посмотреть на примере уже существующего модуля выгрузки в розетку, там добавляются поля к категории, бренду, товарам.
Добавляются они в Okay\Modules\OkayCMS\Rozetka\Init\Init в методе init().
[quote]Я уже просил в теме привести хотя бы один примерчик того, как новосозданная модульность помогает облегчить работу по изменениям в системе. Пока "разработчики быстрого реагирования" спустя два дня еще не удосужились хоть что-то ответить.
Подниму вопрос еще раз: нельзя ли на примере обсуждаемого вопроса продемонстрировать преимущества модульности - дать решение, чтобы отдельный пользователь мог быстренько эту кнопку выгрузки поставить. Чтобы не было неуклюжих глуповатых отмазок типа "я это редко встречал", "это мало кому нужно". Народ тут вполне понимающий, способен самостоятельно без подсказок решить, что кому нужно. А вот разработчикам надо только давать возможности более гибко...[/quote]
По нашей терминологии кнопку ставить может не пользователь, а админ. Но он может установить модуль, который предварительно сделал разработчик.
Админу чтобы установить модуль (если его разработчик корректно оформил) нужно по FTP загрузить файлы модуля в директорию Modules/<Vendor>/<ModuleName>/
Затем зайти в админ-панеле в раздел модули, и напротив нового модуля нажать кнопку "установить". И все, админ за пару минут установил модуль.
В чём преимущество, так это если ранее мы делали модуль, который нужно вставлять между строк "ААА" и "БББ",
затем в окае выходит совсем плёвое обновление, где строка "ААА" изменилась и выглядит как "ввААА".
Код остался обратно совместимым с модулем, но сама строка, которая была ориентиром для установки модуля изменилась,
у многих админов (а иногда и разработчиков) это вызывало затруднения, и модуль нужно было снова обновлять.
Сейчас же такая проблема должна уйти, т.к. весь модуль лежит в отдельной директории и использует системные ресурсы (правда это накладывает определённые ограничения).
Из модуля можно будет добавлять поля и добавлять новые таблицы в БД. Не влазя в саму базу (через PMA или adminer...).
Пример, опять же, посмотрите на модуль выгрузки в розетку, или любой другой модуль в текущем окае, там видно что доработка была реализована только с помощью модульной системы, и код не разбросан по ядру.
P.S. Рекомендую работать в третьем окае в PHPStorm, отличная IDE, и для неё (чаще всего) в коде стоят аннотации, чтобы он понимал экземпляр какого класса лежит в данной переменной.
Всё сказанное мной, является лично моим мнением, и не является официальной позицией OkayCMS
