JohnCMS 7.0.0

# Koenig (17.02.2017 / 17:31)
ramzes, тоже думал про вариант с base64 но хотел тип поля в бд менять, и прям в текст пилить

ты как то странно в код смотрел, посмотри еще раз
в бейс64 кодируется урл картинки только

В репозитории столько много крутых изменений. Нам про них расскажут или это для продвинутых пользователей?

# intelligent (17.02.2017 / 20:12)
В репозитории столько много крутых изменений. Нам про них расскажут или это для продвинутых пользователей?

Добавлен пакет интерфейсов Core API
Доработан класс BBcode

Что тут рассказывать?) С косметической точки зрения изменений не увидишь)
Изменения по коду ток)

# Simba (17.02.2017 / 20:59)
Добавлен пакет интерфейсов Core API
Доработан класс BBcode

Что тут рассказывать?) С косметической точки зрения изменений не увидишь)
Изменения по коду ток)

Ну это понятно. Интересно, какая польза от этого

Вопрос тут возник.
Вот хочу я запилить какой нить модуль.
Мне как быдлокодеру надо несколько базовых вещей.
1. Подтянуть ядро
2. Подтянуть свои классы для модуля
3. Подтянуть конфиги модуля какими нить готовыми средствами, которые по идее есть в CMS.

С первыми двумя в принципе понятно, хоть и второе не очевидно без готовых примеров модулей и без раскопок.
А вот третье не ясно совсем)
Как-то планировалось это вообще или модулеписцы должны пилить свои велосипеды?)

# Simba (17.02.2017 / 21:12)
3. Подтянуть конфиги модуля какими нить готовыми средствами, которые по идее есть в CMS.

Для модуля те конфиги, что лежат в /system/config не нужны, это СИСТЕМНЫЕ конфиги.
Между модулями и системой стоит DI контейнер. В основном для него и написаны конфиги.

Если ты пишешь не расширение системы, а СВОЙ модуль, то и конфигурируешь его на свое усмотрение. Хочешь в базе данных, хочешь в файле. Если модуль - это типа какой-то системы уведомлений, которая всегда активна (фактически является частью системы), то тогда при желании можно и общесистемный конфиг (который виден через контейнер) закинуть.

Ну или если модуль очень большой и сам использует DI навороты, тогда тоже имеет смысл вводить конфигурацию через контейнер (читай - кидать в /system/config)

А так, в большинстве случаев, системные конфиги не трогаешь.

В идеале, ВСЕ общение модуля с ядром системы идет через DI контейнер.
Есть интерфейсы, которые описывают системный API https://github.com/john-cms/jo ... s/Api
Это есть твои инструкции, ты (как писатель модулей) работаешь только с ними и из DI контейнера требуешь только их https://github.com/john-cms/jo ... p#L33

Почему так, сейчас объясню.

Завтра ядро может поменяться, к примеру вместо Zend использована Симфония. или какой-то самопис.
Но тебя это не будет волновать, тебе достаточно знать, что затребованный тобою интерфейс имеет реализацию. То есть, где-то есть код, который выполняет все инструкции, описанные в интерфейсе.
Абстракция
Для того, чтоб изменить реализацию (к примеру, как было в соседней теме, не устраивает класс BBcode и хочется написать что-то свое), достаточно поменять всего одну строку в конфиге.

# AlkatraZ (17.02.2017 / 22:24)
Для модуля те конфиги, что лежат в /system/config не нужны, это СИСТЕМНЫЕ конфиги.
Между модулями и системой стоит DI контейнер. В основном для него и написаны конфиги.

Если ты пишешь не расширени

Не, системные вообще нафик.
Просто есть модуль, у него есть какие-то свои настройки. Т.к. в коде прописывать их не очень интересное решение, нужно что-то типа системного $config = $container->get(Johncms\Config::class);
Только чтобы подтягивался именно тот конфиг, который мне нужен. Пусть он лежит допустим в папке с модулем.
Хоть тут и решается чем-то типа $foo = include 'return.php'; но хочется чего-то более кошерного)

Обычно такие дела с модулем решаются с помощью какого-то локального для модуля конфига.
В случае с зендом - это класс ConfigProvider который лежит в папке с модулем и если он есть, при вызове модуля (ну или при старте системы) подключается https://github.com/mobicms/mob ... r.php

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

# Simba (17.02.2017 / 22:33)
Хоть тут и решается чем-то типа $foo = include 'return.php'; но хочется чего-то более кошерного)

Кошернее этого не придумаешь.
РНР файл-массив имеет множество преимуществ: наивысшая скорость, возможность применения функций и т.д.