Версии 3.6 в июне не будет?

[mikhalkin]

Выпуск версий сдвинулся, так как начал работу над версией PRO. Будет новое ядро с возможностью установки плагинов.

Будет ли какой-то фреймворк использоваться? Если будет, то какой?

[support]

Будут использоваться отдельные компоненты от symfony.
Например сейчас уже применяю https://symfony.com/doc/current/components/yaml.html

[mikhalkin]

Будут использоваться отдельные компоненты от symfony.
Например сейчас уже применяю https://symfony.com/doc/current/components/yaml.html

Прекрасно, хотелось бы что бы было как у фреймворков, публичная часть и не публичная.

Будет ли услуга платная миграция на эту версию?

[support]

Прекрасно, хотелось бы что бы было как у фреймворков, публичная часть и не публичная.

Идея в том, чтоб можно было как в wordpress устанавливать плагины и чтоб они могли автоматом обновляться. Со скрытой частью (которая расположена выше public_html) так не получится сделать, так как нет прав на запись.

Будет ли услуга платная миграция на эту версию?

Про миграцию пока говорить рано.

[Vladzimir]

Сразу вопросы технического характера.

• Будет ли использоваться паттерн MVC?
• Человеческий роутинг?
• Наличие нормального построителя запросов/PDO/маппера. Хоть чего нибудь.
• Шаблонизатор? Шаблонизатор для формул?
• Полноценные события?

[Евгений]

если структура базы данных останется таже, почему нет!?

Структура базы будет другая. Это будет отельный продукт.

Подскажите пожалуйста, СУБД останется только MySQL, использование Постгрес не планируется?

[support]

Ну тут либо MySQL или Постгрес и поскольку MySQL то выбор на него.

[Vladzimir]

Ну тут либо MySQL или Постгрес и поскольку MySQL то выбор на него.

Можно использовать ORM/Mapper который будет абстрацией к БД. Тогда можно будет использовать даже Redis

[support]

Можно использовать ORM/Mapper который будет абстрацией к БД. Тогда можно будет использовать даже Redis

Не подходит, так как ORM/Mapper потребует создание схемы на основе уже существующих таблиц. Пример https://www.doctrine-project.org/projec ... ase-schema
А в Руководители таблицы и поля создаются пользователем.

[Vladzimir]

Не подходит, так как ORM/Mapper потребует создание схемы на основе уже существующих таблиц. Пример https://www.doctrine-project.org/projec ... ase-schema
А в Руководители таблицы и поля создаются пользователем.

Я сторонник лаконичных и элегантных решений, поэтому "монстров" по типу доктрины не использую.
В нормальном дополнении https://github.com/ikkez/f3-cortex к нормальному фреймворку https://github.com/f3-factory/fatfree-core это не составляет проблемы, так как можно динамически, при обращении к классу модели таблицы добавлять схемы. В своем проекте я это реализовал через события https://github.com/ikkez/f3-events. Таким образом я еще помимо стандартных событий, могу навесить события на внесение/удаление/изменение любой записи в любой таблице, что дает неимоверную гибкость. У данного маппера есть еще один бонус - все запросы в базу идут практически атомарные, что делает их мгновенными, и решена классическая проблема N+1.
Ну и порог вхождения в данный фреймворк довольно низкий, а сам он входит в пятерку самых быстрых php-фреймворков, в отличии от новомодных Симфони/Ларавел. Это если кратко.