DE
а чё, норм эта CMS?
По скорости разработки и чистоте кода — лидер
Size: a a a
2019 November 16
DE
Это CMF
SS
По скорости разработки и чистоте кода — лидер
а как оно в сравнении с concrete5? Популярно в РФ? Не заточено под что-то конкретное типа блога как вордпресс?
SS
CMF так-то и битрикс себя называет 🤣 Но очевидно что это полная херь
SS
хм, на Laravel, полагаю должно быть годно весьма
SS
давно PHP не трогал правда
DE
Concrete 5 — полная херь судя по коду. Никакой системности почти
DE
Думаю надо начать с аддонов и автолодера...
Для тех кто устанавливал лару - Pyro имеет некоторые отличия:
В пиро папка app почти пуста (в ней все равно можно писать, но, ай белив - это лишнее). То же самое можно сказать и относительно содержимого папок database и resources.
The best practice - это держать свой код в аддонах.
АДДОНЫ.
Каждый аддон - отдельный пакет на пакаджисте (при желании на гите), и, следовательно - имеет свой composer.json, в котором и прописан PSR-4 неймспейс для автолодера. Все аддоны, являются наследниками одного класса, и всего их пока 5 видов:
1. Module - представляет из себя неймспейс и раздел в админке. Может содержать несколько моделей (streams), а так же полей (fields). Стоит заметить, что поля, могут быть реюзабл в пределах одного неймспейса (модуля) для нескольких моделей (streams). Использование определенного поля, определенной моделью и называется связью (assignment).
2. FieldType - тип поля служит для определения правил миграции и дальнейшего взаимодействия с БД, для одной ячейки данных у модели. Он содержит тип поля, но может содержать аксессор, мутатор, схему - классы в которых и описываются эти правила. Отношения - тоже описываются здесь (я не имею ввиду прямого указания модели).
3. Theme - тема. Тут особо нечего - бывают двух видов: админка и фронт. Показываются в настройках в админке (хран в БД). Может быть перекрыто последовательно, из нескольких мест в ФС (самое сильное - .env)
4. Plugin - это тупо плагин твиг.
5. Extension - с ним ситуация, как с бубями в преферансе: "не с чего ходить - ходи с бубей". Внутри может быть размещена любая логика. Оно может быть связано по универсальному ключу с другими аддонами, что, по сути, является еще одним способом расширения с наследованием, но речь сейчас не о нем.
Важно, что, несмотря на разделение, благодаря общему родителю, аддоны могут пересекаться классами. Например, не обызательно создавать отдельный аддон для плагина, достаточно создать класс плагина в модуле и подключить его в сервис-провайдере. Это касается почти всего.
Класс сервис провайдера может содержать любой из аддонов.
МИГРАЦИИ и устройство БД.
Платформа стримс имеет свой расширенный мигратор, который способен читать миграции, заданные в декларативном стиле. Файлы миграций создаются автоматически, при скаффолде аддонов определенных типов, а также при скаффолде стрима(модели).
The best practice, если мы говорим о модуле, ИМХО - иметь один файл миграции для модуля, в котором описываются все используемые поля, и по одному на каждую модель - в них описываются параметры моделей и принадлежность к ним полей. Важно, что в любой миграции, могут быть использованы стандартные для Ларавел
БД имеет в названиях своих таблиц жесткую зависимость
Структура такова:
- других таблицах с базе и их свойствах (
- полях, которыми имеют возможность обладать таблицы (
- реальных фактах обладания каких-то таблиц, какими-то полями (
Остальные таблицы имеют жесткую зависимость от описаных выше!
А если стрим (ряд) имеет поле
Это не все - могут быть еще вариации конфигураций. Не будем на них останавливаться.
Когда меняется содержимое служебных таблиц (а это модели ларки), наблюдатель триггерит событие Eloquent, которое, в свою очередь, запускает команду - одну из команд - проводящих маленькую миграцию, соответствующую изменениям.
Любые другие таблицы могут быть безболезненно созданы в базе, если только их имена не имеют конфликтов со схемой описанной выше.
Для тех кто устанавливал лару - Pyro имеет некоторые отличия:
В пиро папка app почти пуста (в ней все равно можно писать, но, ай белив - это лишнее). То же самое можно сказать и относительно содержимого папок database и resources.
The best practice - это держать свой код в аддонах.
АДДОНЫ.
Каждый аддон - отдельный пакет на пакаджисте (при желании на гите), и, следовательно - имеет свой composer.json, в котором и прописан PSR-4 неймспейс для автолодера. Все аддоны, являются наследниками одного класса, и всего их пока 5 видов:
1. Module - представляет из себя неймспейс и раздел в админке. Может содержать несколько моделей (streams), а так же полей (fields). Стоит заметить, что поля, могут быть реюзабл в пределах одного неймспейса (модуля) для нескольких моделей (streams). Использование определенного поля, определенной моделью и называется связью (assignment).
2. FieldType - тип поля служит для определения правил миграции и дальнейшего взаимодействия с БД, для одной ячейки данных у модели. Он содержит тип поля, но может содержать аксессор, мутатор, схему - классы в которых и описываются эти правила. Отношения - тоже описываются здесь (я не имею ввиду прямого указания модели).
3. Theme - тема. Тут особо нечего - бывают двух видов: админка и фронт. Показываются в настройках в админке (хран в БД). Может быть перекрыто последовательно, из нескольких мест в ФС (самое сильное - .env)
4. Plugin - это тупо плагин твиг.
5. Extension - с ним ситуация, как с бубями в преферансе: "не с чего ходить - ходи с бубей". Внутри может быть размещена любая логика. Оно может быть связано по универсальному ключу с другими аддонами, что, по сути, является еще одним способом расширения с наследованием, но речь сейчас не о нем.
Важно, что, несмотря на разделение, благодаря общему родителю, аддоны могут пересекаться классами. Например, не обызательно создавать отдельный аддон для плагина, достаточно создать класс плагина в модуле и подключить его в сервис-провайдере. Это касается почти всего.
Класс сервис провайдера может содержать любой из аддонов.
МИГРАЦИИ и устройство БД.
Платформа стримс имеет свой расширенный мигратор, который способен читать миграции, заданные в декларативном стиле. Файлы миграций создаются автоматически, при скаффолде аддонов определенных типов, а также при скаффолде стрима(модели).
The best practice, если мы говорим о модуле, ИМХО - иметь один файл миграции для модуля, в котором описываются все используемые поля, и по одному на каждую модель - в них описываются параметры моделей и принадлежность к ним полей. Важно, что в любой миграции, могут быть использованы стандартные для Ларавел
up() и down() методы.БД имеет в названиях своих таблиц жесткую зависимость
$app_reference, неймспейса и модели.Структура такова:
applications - "корневая" таблица, она имеет связь с applications_domains и это единственные таблицы, имеющие название без префикса. Все другие таблицы имеют в качестве префикса в названии "{$app_reference}_"streams, fields и assignments - это "служебные" таблицы. Они содержат информацию о:- других таблицах с базе и их свойствах (
streams)- полях, которыми имеют возможность обладать таблицы (
fields)- реальных фактах обладания каких-то таблиц, какими-то полями (
assignments)Остальные таблицы имеют жесткую зависимость от описаных выше!
"{$app_reference}_{$namespace_slug}_{$stream_slug}"А если стрим (ряд) имеет поле
translatable === true, то еще и"{$app_reference}_{$namespace_slug}_{$stream_slug}_translations"Это не все - могут быть еще вариации конфигураций. Не будем на них останавливаться.
Когда меняется содержимое служебных таблиц (а это модели ларки), наблюдатель триггерит событие Eloquent, которое, в свою очередь, запускает команду - одну из команд - проводящих маленькую миграцию, соответствующую изменениям.
Любые другие таблицы могут быть безболезненно созданы в базе, если только их имена не имеют конфликтов со схемой описанной выше.
SS
Concrete 5 — полная херь судя по коду. Никакой системности почти
ну хз. Я там сильно не кодил. Порадовало больше визуальное редактирование, версионирование. На практике только лендинг запилил. В PyroCMS есть что-нибудь такое?
DE
Прочитай
SS
Прочитай
прочёл по диагонали. Вроде всё про код в основном. Есть редактирование inplace или не?
DE
В @js_lib посмотри код
DE
Тут нельзя форвард
DE
прочёл по диагонали. Вроде всё про код в основном. Есть редактирование inplace или не?
Прочти нормально. Это я писал
DE
ну хз. Я там сильно не кодил. Порадовало больше визуальное редактирование, версионирование. На практике только лендинг запилил. В PyroCMS есть что-нибудь такое?
Редактирование чего?
SS
Прочти нормально. Это я писал
ещё раз, мне ща не про код больше интересно)))) С позиции юзера как оно? У concrete5 охеренно сделано inplace редактирование (прямо на странице отредачил, поглядел, опубликовал)
SS
Редактирование чего?
контента
DE
PyroCMS — это большще про код. Но я прикручивал grapesjs
DE
Там прикол в админке
DE
В её возможностях