bitrix24/framework3-prototype

framework3-prototype's Issues

Зачем memcache в зависимостях?

Контроллеры: конфликт нейминга

Под контроллерами мы обычно все же принимает некоторое другое значение.

Кажется если мы будем называть "классические контроллеры" и "контроллер компонента" - мы усложним себе жизнь.

Перспектива прототипа в ближайшую пятилетку

Предсталенный прототип можно назвать пестрым, но оторванным от реальности.

Давайте посмотрим непредвзято что у нас имеется в итоге?

С одной строны новый фреймворк это:

• Фреймворко-подобная структура
• Набор "хороших" практик, которые планируется использовать

С другой стороны текущее наследние битрикса:

• Завязка на htaccess (apache) и зависимость от модулей "by design" (пример ntlm авторизация, webdav и другие)
• существующая файловая структура
• сотни тысяч проектов созданных на базе файловой структуре

Отсюда у меня возникают вопросы: как из точки А (текущее наследние), вы хотите прийти в точку Б (новый фреймворк)?

Какие варианты лично я вижу?

1. Утопический мигратор.
   Некоторый код, который за Н хитов или работая в фоне перелопатит существующие публичные страницы и превратит их в новую структуру.
   Мы все понимаем что это непосильная и нереальная задача.

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

3. Куча инструкций по переносу для разработчиков.
   И тут мы понимаем несколько вещей:
   А. Условный Тортик39, который работает на редакции БУС.Малый бизнес раньше не привлекал разработчиков для своей работы и поддержке. Теперь бедной хозяйке придется думать и искать проверенного и квалифицированного разработчика чтобы обновиться до новой структуры.
   Б. Тысячи Битрикс24 инстансов которые нужно будет переделать кому-то. Опять же это ресурсы.
   В. Огромное недовольство тех, кому презентовали БУС как систему где можно настраивать ручками, а тут "на тебе".

4. Развитие в рамках отдельного продукта.
   Это возможно, однако смысл использовать Битрикс, если у тебя нет возможности использовать Битрикс?
   Т.е. получается что на отдельный продукт нельзя накатить модули или поставить приложение.
   В чем тогда смысл использовать его, а не например symfony?

Возможно я что-то упускаю из вида.
Коллеги, давайте подискутируем?

Имплементация PSR стандартов в новом ядре

№	Описание	Требование	status
PER-2.0 / PSR-12	Extended Coding Style Guide	Необходимо имплементировать	ok
PSR-3	Logger Interface	Необходимо имплементировать	ok
PSR-4	Autoloading Standard	Необходимо имплементировать	ok
PSR-6	Caching Interface	Необходимо имплементировать	ok
PSR-7	HTTP Message Interface	Необходимо имплементировать	ok
PSR-11	Container Interface	Необходимо имплементировать	ok
PSR-13	Hypermedia Links	Нет острой необходимости	-
PSR-14	Event Dispatcher	Необходимо имплементировать	- ⁉
PSR-15	HTTP Handlers	Необходимо имплементировать	ok
PSR-16	Simple Cache	Необходимо имплементировать	- ❓
PSR-17	HTTP Factories	Необходимо имплементировать	- ⁉
PSR-18	HTTP Client	Необходимо имплементировать	ok
PSR-20	Clock	Нет острой необходимости	-

Предлагаю внедрить:

1. PSR 14, 17 кажется важно получить
2. PSR 16 для обсуждения

/var/log + /var/cache вместо /cache

Давайте дефолтную директорую для cache и log возьмем как в симфони и поместим в директорию /var.

С возможностью изменения.
Нужен четкий контроль за директориями которые могут изменяться.

Докомпозиция пакетов

1. Рекомендуется не использовать жестко зашитую функциональность в bitrix/main или bitrix/core, а вынести и разбить.

bitrix/cache
bitrix/orm
bitrix/logs
bitrix/http
bitrix/console
И т.п.

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

2. Пакеты которые ориентированны исключительно под битрикс, можно по примеру симфони обозначать дом суффиком bundle

Вспомогательные пакеты, без которых сложно представить разработку: dumper, dotenv

1. dumper (в dev зависимость)
2. dotenv

/var/log + /var/cache вместо /cache

Давайте дефолтную директорую для cache и log возьмем как в симфони и поместим в директорию /var.

С возможностью изменения.
Нужен четкий контроль за директориями которые могут изменяться.

Разработка ядра с прицелом на 2 ЦА: Классическая и Headlesss CMS

Следует понимать при разработке архитектуры что у CMS есть в современное время 2 потребителя:

1. Классическое использование с backend-based render, когда за шаблонизацию отвечает бекенд. Сюда же b24.
2. Современное api-based использование, когда от бекенда требуется только API, а от CMS требуется удобная админка, бизнес логика и возможность писать удобное API (headless CMS).

Требования к модульной архитектуре

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

Требования:

1. Папка модулей должна быть стандартизирована
2. Требования к структуре модулей хотя бы верхнеуровнево должна быть стандартизирована
3. Необходим механизм регистрации модулей в базовом конфиге
4. Модули не должны регистрироваться в базе как в старом битриксе

Хорошее решение для примера: https://symfony.com/doc/current/bundles.html
Давайте возьмем такой же принцип регистрации модуля. Что у модуля есть базовый класс, который мы просто регистрируем в конфиге проекта чтобы его "включить".

Тезисы:

• Наличие модульной структуры в битриксе - это сильная сторона.
• Самый лучший вид монолита - модульный монолит.
• Мы должны сразу задавать правила хорошего тона для разработчиков.
• В противном случае мы получим хаотическую структуру как в типовом laravel, где не было нормального наставника чтобы пояснить за модули.

Почему выбран php/di, а не symfony/dependency-injection?

Редактирование файлов в ФС. Настройки компонентов и решений + создание страниц.

Немаловажная задача - сделать так чтобы клиент по максимуму не мог править файлы.
Возможность править клиентами файлов бич разработчиков которые работают с git, docker, ci/cd.

Текущие источники изменений

1. Создание статических страниц.

Перодически требуется практически всем клиентам.

Костыльное решение в старом битриксе: делаем костыль статических страниц на базе инфоблока.

Возможное решение: предусмотреть возможность создания статических страниц через БД.

2. Изменение параметров компонентов.

Для большинства наших клиентов (средний и крупные) - клиенты не конфигурируют их. Однако для мелких клиентов, гипотетически это может быть необходимо.
У средних и крупных клиентов настроен деплой через docker контейнеры и/или ci/cd которое сотрет их изменения при деплое.

Возможное решение: для мелких клиентов оставить возможность конфигурировать через админку. Для крупных предусмотреть режим выключения такой возможности.

/var/log + /var/cache вместо /cache

Давайте дефолтную директорую для cache и log возьмем как в симфони и поместим в директорию /var.

С возможностью изменения.
Нужен четкий контроль за директориями которые могут изменяться.

Сразу заложить Console

Консольный интерфейс должен быть заложен в основу и развиваться вместе с функционалом.
Команды должны быть неотъемлемой частью модулей.

Отправляется только тело, а заголовки нет :(

framework3-prototype/public/index.php

Line 20 in d53d119

echo $response->getBody();

Миграции

Новый фреймверк обязательно нужно выпускать с удобным инструментом для миграций.
Не обязательно изобретать свой, можно взять любой open source движок типа phinx.

/var/log + /var/cache вместо /cache

Давайте дефолтную директорую для cache и log возьмем как в симфони и поместим в директорию /var.

С возможностью изменения.
Нужен четкий контроль за директориями которые могут изменяться.