Hetzerok

Hetzerok

Был в сети 04 июня 2019, 15:37
Заказы принимаю
Круто что серьезная работа работа началась, однако те вещи, которые были названы в начале (проблемы XPDO, отсутствие файловых элементов, extJS и т.д.) это краеугольные камни MODX. Получается что если отказаться от XPDO например в следующем релизе, то это минимум MODX4, а вероятнее этого не произойдет никогда. Между тем это не то что нужно уже сейчас, а нужно было вчера.
Проблема MODX не в том что он плох, а в том что он стремительно устаревает на уровне своих принципов. Да что говорить — автозагрузка классов в современном виде фишка 2009 года, а в MODX у нас loadClass бессменный.
Ну естественно. Вообще количество информации увеличивается, просто в ИТ сфере это очень заметно, так как происходит гораздо быстрее. Так это логично в виду темпов развития индустрии. Но, как я уже писал, в условиях появления множества идентичных технологий почему бы не остановиться на чем-то одном? Это позволит как раз добиться глубины знаний.
Ещё момент, поскольку вы недавно начали заниматься программированием может быть вам будет это полезно хотя вещь то банальная.
В первую очередь стоит изучить принципы на которых строится технология, тогда будет гораздо проще работать с чем то новым, но основанным на тех же принципах.
Например ООП — независимо от языка принципы полиморфизма, инкапсуляции и наследования остаются неизменными, так остается разница только в синтаксисе. Да и синтаксис современных языков практически идентичен, а уж посмотреть какие функции существуют — всегда есть документация.
Зная алгоритмы вы уже будете знать как решается задача — все что останется это подсмотреть как записать решение с помощью нужного языка.
Зная как устроены РСУБД для вас не будет принципиальной разницы в том MySQL это Postgres или MsSQL.
Ну зоопарк технологий плодится по многим причинам. Есть конечно и веяния моды и желание идти в ногу со временем, но по большей части что-то новое появляется тогда когда в старом не хватает функционала или находится другой путь, кажущийся создателю более логичным и удобным.
Что касается человека который будет работать уже с этими технологиями то почему бы не выбрать что-то одно и не работать с ним, так сказать увеличивать глубину а не ширину знаний. Например у вас в списке 6 cms — смысл знать их все? Sass, Less — это одно и то же под разным соусом, только PostCss не хватает. Phenom, Smarty (ещё куча есть шаблонизаторов и для PHP и для JS) — почему не работать с одним? Laravel и Symfony — какую задачу можно решить на одном фреймворке и нельзя на другом? И это вы ещё не окунулись в волшебный мир фронтенда — вот где разнообразие так разнообразие.
Смысл такой: большая часть элементов вашего списка дублирует друг друга, так что можете смело от них отказаться)
Почему кинуть, разговор же идет не о прекращении поддержки 2.x, а о том что будет в 3.x. Вон Evolution до сих пор существует и пользуется заслуженной любовью у многих разработчиков.
Вот ещё скажу может быть крамольную мысль — MODX не повредил бы отказ от XPDO в его существующем виде. В него запихано все что возможно и ORM и валидация и загрузка нлассов и т.д. Чтобы соответствовать современным требованиям нужно это разделять.
Так в первую очередь нужен план действий какой-то — четкое понимание «Мы хотим видеть MODX таким-то», а уж к этому нужно прикладывать усилия разработчиков. Пока что, как я понимаю, такого плана нет — не ясно даже будет ли в следующей версии кардинальное обновление или продолжится процесс эволюции.
Да безусловно MODX нуждается в глобальной модернизации. Технологии как и тренды не стоят на месте, а основой движка остается кодовая база 2010 года.
На мой взгляд как разработчика необходимы следующие изменения:
— Поддержка PSR стандартов и все что с этим связано (неймспейсы, автозагрузка, composer)
— Полноценный шаблонизатор из коробки (не важно smarty, fenom, twig или ещё что-то)
— Отделение кодовой части от БД, что позволит нормально пользоваться системами контроля версий, а не изобретать велосипед.
— Отказ от ExtJS в админке и переход на один из современных JS фреймворков.
— Слабосвязанная архитектура, чтобы любую часть системы можно было легко заменить.
— CLI приложение для типовых задач (парсинг схемы, создание базы компонента и т.д.)