framework3-prototype's People
Forkers
dmsk73 gilyazov champernet betensis alex19pov31 mshrzz itdepartament stregubov lukoyanov-aa vladimirzasorin wheeliejoe sline-xframework3-prototype's Issues
/var/log + /var/cache вместо /cache
Давайте дефолтную директорую для cache и log возьмем как в симфони и поместим в директорию /var.
С возможностью изменения.
Нужен четкий контроль за директориями которые могут изменяться.
Миграции
Новый фреймверк обязательно нужно выпускать с удобным инструментом для миграций.
Не обязательно изобретать свой, можно взять любой open source движок типа phinx.
Почему выбран php/di, а не symfony/dependency-injection?
Разработка ядра с прицелом на 2 ЦА: Классическая и Headlesss CMS
Следует понимать при разработке архитектуры что у CMS есть в современное время 2 потребителя:
- Классическое использование с backend-based render, когда за шаблонизацию отвечает бекенд. Сюда же b24.
- Современное api-based использование, когда от бекенда требуется только API, а от CMS требуется удобная админка, бизнес логика и возможность писать удобное API (headless CMS).
Редактирование файлов в ФС. Настройки компонентов и решений + создание страниц.
Немаловажная задача - сделать так чтобы клиент по максимуму не мог править файлы.
Возможность править клиентами файлов бич разработчиков которые работают с git, docker, ci/cd.
Текущие источники изменений
1. Создание статических страниц.
Перодически требуется практически всем клиентам.
Костыльное решение в старом битриксе: делаем костыль статических страниц на базе инфоблока.
Возможное решение: предусмотреть возможность создания статических страниц через БД.
2. Изменение параметров компонентов.
Для большинства наших клиентов (средний и крупные) - клиенты не конфигурируют их. Однако для мелких клиентов, гипотетически это может быть необходимо.
У средних и крупных клиентов настроен деплой через docker контейнеры и/или ci/cd которое сотрет их изменения при деплое.
Возможное решение: для мелких клиентов оставить возможность конфигурировать через админку. Для крупных предусмотреть режим выключения такой возможности.
Отправляется только тело, а заголовки нет :(
framework3-prototype/public/index.php
Line 20 in d53d119
Перспектива прототипа в ближайшую пятилетку
Предсталенный прототип можно назвать пестрым, но оторванным от реальности.
Давайте посмотрим непредвзято что у нас имеется в итоге?
С одной строны новый фреймворк это:
- Фреймворко-подобная структура
- Набор "хороших" практик, которые планируется использовать
С другой стороны текущее наследние битрикса:
- Завязка на htaccess (apache) и зависимость от модулей "by design" (пример ntlm авторизация, webdav и другие)
- существующая файловая структура
- сотни тысяч проектов созданных на базе файловой структуре
Отсюда у меня возникают вопросы: как из точки А (текущее наследние), вы хотите прийти в точку Б (новый фреймворк)?
Какие варианты лично я вижу?
-
Утопический мигратор.
Некоторый код, который за Н хитов или работая в фоне перелопатит существующие публичные страницы и превратит их в новую структуру.
Мы все понимаем что это непосильная и нереальная задача. -
Постепенная трансформация.
Новые проекты разворачиваются с новой структурой, старые с старой.
Непонятно где брать ресурсы для развития и поддержки обеих форм, ведь они не одинаковые. -
Куча инструкций по переносу для разработчиков.
И тут мы понимаем несколько вещей:
А. Условный Тортик39, который работает на редакции БУС.Малый бизнес раньше не привлекал разработчиков для своей работы и поддержке. Теперь бедной хозяйке придется думать и искать проверенного и квалифицированного разработчика чтобы обновиться до новой структуры.
Б. Тысячи Битрикс24 инстансов которые нужно будет переделать кому-то. Опять же это ресурсы.
В. Огромное недовольство тех, кому презентовали БУС как систему где можно настраивать ручками, а тут "на тебе". -
Развитие в рамках отдельного продукта.
Это возможно, однако смысл использовать Битрикс, если у тебя нет возможности использовать Битрикс?
Т.е. получается что на отдельный продукт нельзя накатить модули или поставить приложение.
В чем тогда смысл использовать его, а не например symfony?
Возможно я что-то упускаю из вида.
Коллеги, давайте подискутируем?
/var/log + /var/cache вместо /cache
Давайте дефолтную директорую для cache и log возьмем как в симфони и поместим в директорию /var.
С возможностью изменения.
Нужен четкий контроль за директориями которые могут изменяться.
Зачем memcache в зависимостях?
Контроллеры: конфликт нейминга
Под контроллерами мы обычно все же принимает некоторое другое значение.
Кажется если мы будем называть "классические контроллеры" и "контроллер компонента" - мы усложним себе жизнь.
Докомпозиция пакетов
- Рекомендуется не использовать жестко зашитую функциональность в bitrix/main или bitrix/core, а вынести и разбить.
bitrix/cache
bitrix/orm
bitrix/logs
bitrix/http
bitrix/console
И т.п.
C менее жесткой связью, чтобы некоторые пакеты можно было легко заменять на основанных стандартах.
А некоторые пакеты на основе PSR можно сразу не изобретать велосипед, а просто переиспользовать...
- Пакеты которые ориентированны исключительно под битрикс, можно по примеру симфони обозначать дом суффиком bundle
Сразу заложить Console
Консольный интерфейс должен быть заложен в основу и развиваться вместе с функционалом.
Команды должны быть неотъемлемой частью модулей.
Имплементация 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 | Нет острой необходимости | - |
Предлагаю внедрить:
- PSR 14, 17 кажется важно получить
- PSR 16 для обсуждения
/var/log + /var/cache вместо /cache
Давайте дефолтную директорую для cache и log возьмем как в симфони и поместим в директорию /var.
С возможностью изменения.
Нужен четкий контроль за директориями которые могут изменяться.
/var/log + /var/cache вместо /cache
Давайте дефолтную директорую для cache и log возьмем как в симфони и поместим в директорию /var.
С возможностью изменения.
Нужен четкий контроль за директориями которые могут изменяться.
Требования к модульной архитектуре
В видео озвучен тезис про любую папку для своих модулей.
Возможно имелось ввиду что это только на стадии прототипа, однако точно нужна жесткая стандартизация модулей.
Требования:
- Папка модулей должна быть стандартизирована
- Требования к структуре модулей хотя бы верхнеуровнево должна быть стандартизирована
- Необходим механизм регистрации модулей в базовом конфиге
- Модули не должны регистрироваться в базе как в старом битриксе
Хорошее решение для примера: https://symfony.com/doc/current/bundles.html
Давайте возьмем такой же принцип регистрации модуля. Что у модуля есть базовый класс, который мы просто регистрируем в конфиге проекта чтобы его "включить".
Тезисы:
- Наличие модульной структуры в битриксе - это сильная сторона.
- Самый лучший вид монолита - модульный монолит.
- Мы должны сразу задавать правила хорошего тона для разработчиков.
- В противном случае мы получим хаотическую структуру как в типовом laravel, где не было нормального наставника чтобы пояснить за модули.
Вспомогательные пакеты, без которых сложно представить разработку: dumper, dotenv
- dumper (в dev зависимость)
- dotenv
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.