Обновление версии bootstrap

[aik]

Хорошее сравнение ))) ну если все прям на столько серьёзно, тогда предложение конечно неактуально ))

[support]

Антон, вы конечно правы со свое стороны и я уже не раз порывался обновить bootstrap. Но тут дело в том, что процентов 30 пользователей используют какой то свой CSS и js код или вовсе свои темы.
Это все перестанет работать и будут проблемы с обновлением или люди вообще не захотят обновляется.
По этому я принял решение оставить все как есть и сосредоточится на функциональности.

В планах вовсе переделать ядро Руководителя. Это будет новый проект и вот там я уже конечно же применю новую версию bootstrap.

[Vladzimir]

А если не секрет, на что посматриваете?
Мое видение чего нехватает системе: MVC, нормальный ActiveRecords/PDO/QueryBuilder/DataMapper, events, routing.
Есть отличный микрофреймворк! без серьезных зависимостей и строгих рамок создания приложения, которые все это умеет из коробки - https://fatfreeframework.com. Есть отличный плагин для событий, который позволяет навесить любое событие как на класс-функцию, так и на insert/update/delete в БД. Что позволяет существенно раширить систему без внесения изменеий в код.

[support]

Проект только в мечтах пока, я еще ничего не решил, но фреймворк я точно не буду использовать. Рано или поздно фреймворк перестают поддерживать и потом весь проект из за этого загибается. У меня уже был печальный опыт с https://symfony.com Они выпустили новую версию, которая со старой не совместима и старую перестали поддерживать. Соответственно на новых версия пхп она не работает.

[Vladzimir]

Но и писать велосипеды, тоже не выход.
Фреймворк, на то и используется, что решает 95% насущных вопросов при разработке.
Ну и всегда можно стать контрибутором фреймворка или сделать свой форк. При том что это микрофрейморк, там нет портянок кода и кучи зависимостей.

[support]

https://fatfreeframework.com/ заинтересовал, изучу его на досуге, может что то и возьму от туда.

Но и писать велосипеды, тоже не выход.

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

[Vladzimir]

Ну почему же? Я например там нашел один баг, сделал пулл реквест, контрибутор сделал коммит. Все довольно быстро. К тому же есть активный чат в слаке, где оперативно можно задать вопрос, и где сидят основные разработчики.

[alexinc]

Мне вот нравиться Руко в текущем состоянии. Он очень хорошо вписывается в нишу малого и среднего бизнеса. Особенно, малого и микро. Тут главное не вид даже, а функционал,скорость разработки, вменяемая стоимость (пока).
Есть ли смысл перескакивать и скакать? Вопрос. Развиваться есть куда, работы на несколько лет - точно есть.
С фреймворкерами есть проблема - это версионность, Сергей прав. Мы делали на Django внутреннюю систему учета. Все хорошо, но при прекращении поддержки версии, начинается возня, копиться технический долг. В итоге, цикл жизни сокращается и встаешь на распутье - бросать или подпрыгивать. Мне кажется, в таких системах нельзя быстро и часто обновлять ядро, движок. Переход будет очень болезненным.
Для себя, для уже более серьезных вещей мы себе присмотрели LsFusion (не реклама). Но это уже более серьезная система, для более крупного бизнеса.

[Vladzimir]

С фреймворкерами есть проблема - это версионность, Сергей прав.

Я понатуре перфекционист.
Поэтому я и предлагаю идеальный (не побоюсь этого слова) фреймворк, для КАЧЕСТВЕННОГО роста проекта Руководитель.
Что даст проекту использование данного фреймворка:
* чистоту кода! (Сергей, извини, но текущий код проекта вызывает противоречивые чувства, например global в коде)
* отделения "мух от котлет" (кода от дизайна и дизайна от запросов)
* гибкость и масштабируемость (инвалидация кеша запросов, гибкое кеширование запросов, хранение сессий в любой удобной среде, а не тольк в БД/файлах, возможность навесить событие на любую функцию/запрос, настроить крон для запуска из одной точки с его гибкой конфигурацией именно в настройках системы, а не сервера)
* решения многих "детских болезней" руководителя, начиная от автоматического экранирования данных в sql-запросах до использования различных баз данных от mysql до mongo

На счет версионности так же могу опровергнуть, указанный мной фреймворк до сих пор поддерживает php 5.4! и при этом спокойно работает на 7.4
И при всей своей скромности он имеет низкий порог вхождения и максимальную производительность, даже по отношению к голому php.

[alexinc]

С фреймворкерами есть проблема - это версионность, Сергей прав.

Я понатуре перфекционист.
Поэтому я и предлагаю идеальный (не побоюсь этого слова) фреймворк, для КАЧЕСТВЕННОГО роста проекта Руководитель.
Что даст проекту использование данного фреймворка:
* чистоту кода! (Сергей, извини, но текущий код проекта вызывает противоречивые чувства, например global в коде)
* отделения "мух от котлет" (кода от дизайна и дизайна от запросов)
* гибкость и масштабируемость (инвалидация кеша запросов, гибкое кеширование запросов, хранение сессий в любой удобной среде, а не тольк в БД/файлах, возможность навесить событие на любую функцию/запрос, настроить крон для запуска из одной точки с его гибкой конфигурацией именно в настройках системы, а не сервера)
* решения многих "детских болезней" руководителя, начиная от автоматического экранирования данных в sql-запросах до использования различных баз данных от mysql до mongo

На счет версионности так же могу опровергнуть, указанный мной фреймворк до сих пор поддерживает php 5.4! и при этом спокойно работает на 7.4
И при всей своей скромности он имеет низкий порог вхождения и максимальную производительность, даже по отношению к голому php.

Вопрос в поддержке - отвалиться команда - что делать? Форкать? Выпустят новую версию, поломают совместимость - что делать? Форкать?
Нашли ошибку - где искать? В фреймвоке? В системе что на ней построены?
В полный рост встает вопрос о команде. Не одном-двух человек, а хорошей команде из 4-5 человек, которые пишут, парсят, поддерживают.
Что делать с базами данных? там используется ORM - это накладывает ограничения на производительность обращения к базе данных (возможны внутри неэффективные запросы, невозможность агрегация запросов). При оптимизации ORM - мы сразу привязываемся к базе. Очень не простой вопрос. (Взять вот наихудший пример нашей жизни - работа с запросами в 1С, притча во языцах. Зато почти любая база: Postgresql, MSSQL, IBM DB и т.д.).
Я не зря Django привел в пример. Они очень долго переезжали с версии python 2 на версию 3. Когда переехали, поломалась совместимость, и код пришлось адаптировать. Когда у тебя это все работало около 3-5 лет, это оказалось очень тяжело.
Не спорю, код от шаблонов нужно отделять, это как бы правило. Но думаю, Руко начался как локальный проект, которые подрос. И подрос достаточно быстро - и накопился техдолг. Рано или поздно его придется оплатить.
Вопрос только в том - как это сделать, чтобы не обрушить инфраструктуру: самой программы, разработчиков, пользователей.