Честно говоря, у нас пока нет точных ответов. Есть только некоторые части информации, которые мы можем сложить вместе. Поскольку MODX 3 еще попросту не создан, существует множество допущений и «продвинутых» предположений. MODX 3 – это долгосрочный проект, который только запускается.
Почему нам все равно нужен MODX 3?
Множество людей отлично пользуются текущей версией MODX. Система позволяет дизайнерам и фронтенд разработчикам создавать полностью уникальные сайты с минимальными усилиями и изменениями ядра в отличие от некоторых конкурентов. Даже в текущей версии разработка сайтов будет простым и полностью осуществимым делом в течение многих последующих лет. Очень мощный язык шаблонов и элементов, дополнительные поля (TV) и расширения – все это уже готово для использования в будущем.Возможно, наибольшая причина, почему нам нужен MODX 3, – это просто число. С целью очищения унаследованного кода и предоставления разработчикам улучшенных средств, соответствующих стандартам отрасли, системе MODX будут нужны критические изменения. А поскольку MODX следует принципам семантического версионирования, это означает, что мажорная версия должна увеличиться в момент реализации критических изменений. Для MODX Revolution установлена версия №2, значит, нам будет нужна версия №3.
Так почему же нам нужны критические изменения, если текущая версия MODX все еще очень актуальна? Я бы сказал, это нужно для того, чтобы MODX следовал в потоке изменений мира PHP. Сообщество PHP становится более профессиональным и стандартизированным (в частности, благодаря The Framework Interoperability Group – группе концепции совместимости и инициативам вроде PHP: The Right Way – PHP: правильный путь) с впечатляющей скоростью в последние несколько лет. Включаясь в это движение, код ядра MODX может стать намного более классным (читай: стабильным, тестируемым и, возможно, меньше по объему). И наоборот, MODX стал бы намного более привлекательной платформой для других разработчиков на PHP.
В мире разработки критические изменения происходят постоянно. С исключительным прыжком от Evo к Revo MODX стал на самом деле стабильнее и продолжал развиваться в прошедшие года, но с определенных точек зрения критический релиз должен произойти, чтобы превзойти все то, что позволяет существующий код.
Синдром «это придумали не мы»
Во многих случаях MODX был разработан при использовании концепции «неприятия чужой разработки» (тенденция сознательно или инстинктивно игнорировать все инновации, которые происходят за пределами организации – прим. переводчика), являющейся не лучшим паттерном проектирования. В основном это означает, что если ранее каждая часть кода была разработана внутри сообщества MODX, то в будущем могут быть использованы более стандартизированные библиотеки, которые разработаны внешними сообществами. Благодаря Composer и Packagist, такое изменение произошло внутри сообщества PHP в последние годы, что позволило максимально просто использовать код внешних разработчиков, а также ускорило рост отдельных библиотек, выполняющих исключительно хорошо одну, четко определенную задачу.Подключая такие внешние библиотеки сторонних разработчиков, становится возможным разрабатывать надежные приложения быстрее и лучше, используя преимущества полностью протестированного кода отдельных модулей (юнит тесты). Поскольку сейчас в MODX нет никаких полезных юнит тестов (хотя все же существует некоторое движение), это имеет большое значение с точки зрения архитектуры и качества кода.
Приведу некоторые примеры модулей, которые были разработаны внутри команды MODX ранее до использования внешних библиотек:
- Журналирование. На данный момент существует удобный метод $modx->log(), однако при изменении данного метода в соответствии с поддержкой интерфейса PSR-3 разработчики смогут сбрасывать записи лога в различные системы журналирования, например, в такие, как Monolog. Система Monolog предоставляет огромное количество впечатляющих возможностей по управлению логами, и когда MODX начнет поддерживать PSR-3, можно будет поддерживать любые из них без изменения ядра MODX.
- Маршрутизация. Существуют библиотеки, которые могут делать довольно крутые штуки с трансформированием запроса в правильный ответ. Смотрите раздел о фреймворке Slim ниже.
- Система шаблонов. Честно говоря, мне действительно нравится язык шаблонов в Revolution, но, возможно, использование чего-то более «стандартного» наподобие Twig могло быть интересным улучшением. В любом случае это снизит кривую обучения для многих людей, поскольку Twig используется во многих других проектах.
Что такое Slim и зачем его использовать?
Во второй части серии своих статей «Поддерживая MODX в актуальном состоянии», Джейсон отметил фреймворк Slim (версия 3) как наиболее вероятного кандидата для использования в ядре MODX. Это не прошло незамеченным – многие люди начали рассматривать Slim, выясняя, что это такое и как он работает.Вот что нам нужно знать о Slim:
- Slim – это маршрутизатор. Он трансформирует Запросы (например, GET /manager/resource/update) в Ответ (например, в форму для обновления ресурса).
- Slim поддерживает паттерн Middleware (промежуточное программное обеспечение). При использовании данного паттерна вы по существу получаете множество слоев, которые обрабатывают каждый отдельный запрос, а также ответы с возможностью менять их до того, как они достигнут следующего слоя. Техническое объяснение паттерна Middleware можно найти здесь. Паттерн Middleware – это очень эффективный путь для расширения поведения. Slim 3 фактически поддерживает стандарт PSR-7 (черновик) из PHP FIG в его реализации Middleware, что означает, что любой middleware-код с поддержкой паттерна PSR-7 может быть спокойно использован вместе с Slim 3.
- Slim 3 пока еще находится в разработке; иными словами, он еще не готов для работы в реальном производстве, но похоже, код Slim 3 становится стабильным.
Что насчет Менеджера и ExtJS?
Если вы спросите случайную группу MODX-разработчиков об их самой нелюбимой части системы, скорее всего, это будет ExtJS (или в более общей форме – «Менеджер»). На данный момент пока не существует определенного направления для Менеджера, о котором я бы знал, но привязка к ExtJS 3.4 – это явно не то, что должно произойти. ExtJS 3 очень устарел, он недостаточно быстрый и не обеспечивает должной поддержки мобильных устройств. Более того, ExtJS 3.4 больше не обновляется, поскольку ExtJS 6 уже доступен в раннем доступе.Так что хотя мы пока не знаем, как будет выглядеть Менеджер или на чем он будет построен, мы можем быть вполне уверены, что это не будет ExtJS 3.
Но что же мы знаем?
Учитывая выбор Джейсона в виде Slim как библиотеки ядра, его работы над неким проектом Tacit («высокопроизводительным RESTful фреймворком», основанном на Slim), а также некоторые обсуждения в различных IRC каналах и Slack, наиболее похоже, что следующий Менеджер получит RESTful API в качестве своей основы. Текущий Менеджер также обладает API, но его структура не полностью стандартизирована, а местами направлена именно на то, что от него ожидает ExtJS. Определенно, это не RESTful.
При переходе на RESTful API в качестве основной службы бекенд и интерфейс будут дополнительно разделены с точки зрения кода. Это должно позволить проще разрабатывать по-настоящему уникальные Менеджеры, причем делать эти две части платформы независимо друг от друга. Дизайнеры могли бы сфокусироваться на разработке интерфейса Менеджера третьей версии, а разработчики тем временем работали бы над надежным API.
Что дальше?
Прямо сейчас Джейсон работает над долгожданной третьей частью своей серии статей о будущем MODX. В этой части он поделится своим видением на тему устойчивости – в основном, взаимодействия с базой данных. Для архитектуры MODX это очень важное решение, поэтому Джейсон готовит несколько возможных вариантов перед публикацией результатов.На данный момент основной фокус MODX – это версия 2.3 и приближающаяся версия 2.4. Выпуск MODX 3 обещает стать захватывающим и привлекательным, так что важно потратить некоторое время для выработки решений перед определением основ новой революции в MODX.
Автор статьи: Mark Hamstra,
оригинал: modx.today/posts/2015/05/what-do-we-know-about-modx-3
Воеводский Михаил 01.06.2015 14:17 #
Игорь, спасибо за перевод.
Игорь Сухинин 01.06.2015 14:20 #
Воеводский Михаил 01.06.2015 14:21 #
Антон Пастухов 02.06.2015 11:50 #
Первая часть Keeping MODX relevant опубликована 11 февраля. Почти четыре месяца назад. Вторая — 24 февраля. И сейчас, 2 июня, главный архитектор MODX не может собраться с силами и… реализовать задуманное? Нет, всего лишь озвучить дальнейшие планы, выдав, наконец, третью часть. Интересно, сколько времени уйдет на реализацию этого?
«Talk is cheap. Show me the code» — замечательная цитата Торвальдса. И код MODX показывает нам все — количество незакрытых тикетов на гитхабе приближается к 1000, 60 pull-request-ов, самому старому уже год — висят без реакции. Не приняты, не отклонены — просто проигнорированы. Смешно слушать про то, что другие CMS «догоняют» MODX — они не только догнали, но и перегнали уже давно, пока мы все ждем 3.0. И это при том, что разговоры о накопившемся техническом долге идут с 2012 года.
Короче, не верю в 3.0.
В дополнение: пока MODX собирался с духом, PSR-7 уже реализован в последней версии Symfony.
Игорь Сухинин 02.06.2015 12:03 #
>> Смешно слушать про то, что другие CMS «догоняют» MODX — они не только догнали, но и перегнали уже давно, пока мы все ждем 3.0.
Может быть, тогда приведете примеры этих CMS? Я совершенно серьезно спрашиваю. Может быть, я отстаю от жизни просто :)
>> PSR-7 уже реализован в последней версии Symfony.
Однако, Symfony — это чистый фреймворк. Они же не развивают направление в CMS, насколько мне известно. Я могу взять Symfony и построить свою CMS — не вопрос. Но насколько она получится удобной, гибкой и т.п. — это останется только в моей компетенции.
Евгений Дурягин 07.06.2015 15:55 #
Антон Пастухов 02.06.2015 12:32 #
Игорь Сухинин 02.06.2015 13:38 #
Craft — это оно buildwithcraft.com/? Вроде как оказался платным. В бесплатной версии много чего урезано. Тем не менее, изнутри CMS выглядит куда более проработано и профессионально. Хотя… я бы сказал, что MODX Revo выглядит все же удобнее для end user. И дело даже не в привычке — я немного разбираюсь в интерфейсном дизайне.
October — вот это уже интересно, да. Изнутри достаточно дружественный интерфейс имеет (хотя и относительно примитивного вида) + основан на Laravel. Вопрос, насколько гибкая система — не знаю, но наличие готовых шаблонов можно считать как плюсом, так и минусом. Например, для MODX найти готовые шаблоны
ну почтинереально.Антон Пастухов 02.06.2015 12:33 #
Игорь Сухинин 02.06.2015 13:49 #
Запустил демо 8 версии тут simplytest.me/ — ну, да, Drupal сильно поменялся с момента, когда я его последний раз видел изнутри :) Хотя чувствуется еще наследие старого грубого интерфейса все же. Но если это все основано уже на Symfony, то… молодцы, что тут скажешь.
В общем, да, постепенно появляется конкуренция. Хотя и не сказать, что прям заметны какие-то потрясающие лидеры. Так что у ребят из MODX есть время, чтобы выдать нам свой крутой продукт. Я по крайней мере на это надеюсь :)
Антон Пастухов 02.06.2015 13:56 #
Алексей Александрович 08.06.2015 21:08 #
Гибкость MODX вещь сомнительная, к примеру что бы накидать сайт типа блога с админкой и категориями на Laravel нужен один день, а потом эту сборку вообще за пол дня можно развернуть. Тоесть из фремворков ушел хардкор, лично у меня к примеру уже есть готовые сборки блога магазина, разворачивается за несколько минут.
История с ТВ полями очень сомнительна так как это стринговое поле подтянутое через JOIN при построении фильтров и сортировок эта жесть не несусветная. В то время как во всех современных фремворках расширить модель и добавить поле да хоть целую таблицу это дело наката одной миграции.
Тоесть для вменяемого серверного разработчика с минимальным знанием фронтенда, создать свою сборку с блекджеком и ш… хами дело пару недель максимум.
Таки и зачем вообще нужны тогда CMS когда все это можно сделать с помощью конфигов и немного кодинга?
Единственное кому нужены CMS это сайта строителям, так им гибкасть MODX не кчему вообще у них только одно желание, это накликать мышкой сайт на бесплатном шаблоне за вечер, а MODX таких решений не имеет в отличии от вордпреса на котором даже ребенок сайт соберет не нажав не одной кнопке на клаве (штка но близко к правде).
MODX больше похож на конструктор лего для взрослых, типа:
Почувствуй себя вебразработчикм!
Стань серверным программистом уже сегодня!
На MODX можно собрать сайт не зная даже что такое ООП!
это круто для тех кто имеет свой сайтик и пилит его по вечерам, но для кровавого ентерпрайза это не подходит.
Если MODX уйдет в сторону фремворка в современном его понятии, то там его ждут такие мастадонты как Laravel, Symfony, Zend, тяжко будет
Если MODX пойдет в сторону CMS то тут тоже хватает проектов с гиганским количеством готовых шаблонов и решений типа тогоже друпала, вордпреса или жумлы
У MODX есть только одна не занятая ниша в которой он вполне успешен, конструктор лего для взрослых, вот только ExtJS надо заменить на что то более дружелюбное.
Игорь Сухинин 26.06.2015 09:56 #
>> Гибкость MODX вещь сомнительная, к примеру что бы накидать сайт типа блога с админкой и категориями на Laravel нужен один день…
Отлично, но как будет выглядеть эта админка? Сдается мне, что это будет довольно топорный внешний вид. Я лично немало видел подобных разработок. Да, внутри этой системы крутится современный фреймворк типа Symfony, но из-за неудобного/неочевидного/запутанного интерфейса пользователи рыдают. Если же разрабатывается удобный интерфейс для отдельного проекта, то стоимость разработки именно CMS на фреймворке резко возрастает (т.к. подключаются еще дизайнеры/UI специалисты) и в итоге проект становится дороже, чем если бы использовался готовый интерфейс.
>> История с ТВ полями очень сомнительна… В то время как во всех современных фремворках расширить модель и добавить поле да хоть целую таблицу это дело наката одной миграции.
Вот тут согласен целиком и полностью, это реально беда MODX. И она очень чувствительно проявляется на относительно объемных проектах.
>> MODX больше похож на конструктор лего для взрослых
Нет, не похож совсем. Конструкторы сайтов — это из другой категории. Возможно, близко к этому находятся Joomla и Wordpress со своими готовыми шаблонами, да и то не совсем. Вы много видели готовых шаблонов для MODX?
>>… для кровавого ентерпрайза это не подходит
А что, вот прямо всем нужен «кровавый энтерпрайз»? По-моему, никто не позиционировал MODX для таких целей. Я всегда говорю о том, что MODX идеален для сайтов малого размера и более-менее для сайтов среднего размера, если брать в общем.
Для сложных, комплексных проектов нужно подбирать уникальные решения — да, здесь как раз годятся упомянутые фреймворки (причем зачастую выбор конкретного фреймворка — это еще одна сложная задача). А иногда даже вообще рассматриваются решения на уровне выбора языка программирования, а не конкретной реализации фреймворка в PHP.
>> Если MODX уйдет в сторону фремворка в современном его понятии
Сомневаюсь, что такое когда-то случится. В этом нет смысла, т.к. MODX — это CMS/CMF. Иначе MODX потеряет свою идеологию и тогда нам не о чем говорить, будем сравнивать просто разные фреймворки между собой.
>> Если MODX пойдет в сторону CMS то тут тоже хватает проектов с гиганским количеством готовых шаблонов и решений
Ну и пусть себе живут эти проекты с множеством шаблонов. Перефразируя классика, если ими пользуются, значит, это кому-то надо. Аналогично и с MODX, не зря такое количество людей используют эту систему.
>> У MODX есть только одна не занятая ниша… — конструктор лего для взрослых
Пожалуй, ниш все же больше :) Не сочтите за рекламу, но нам удается разрабатывать сайты в большом диапазоне www.bdcolors.ru/primery-rabot/ — большинство работ основаны на MODX. И да, я считаю это именно разработкой, а не собиранием сайтов из конструктора. Иначе можно также считать, что использование фреймворка — это тот же конструктор, т.к. в этом случае мы также берем за основу огромное количество готового кода, включающего в себя десятки разных модулей.
Алексей Александрович 01.07.2015 18:11 #
Начнем сначала. Действительно лет этак 5 тому назад UI часть была проблемой, но не сейчас, что мешает использовать следующие решения для интерфесов
www.jqwidgets.com
www.jeasyui.com
только контроллеры описать надо, остальное все из каробки.
не устраивает лицензия, можно использовать
тот-же angular или knockoujs с помощью этих чудесных инструментов можно такое собрать что во сне не приснится..))
Да действительно придется один раз потратить время на написания интерфейса, а потом его можно использовать многократно.
по личной практике могу сказать что на knockoujs набросать компонент намного быстрее чем сделать это на ExtJS а самое главное это будет действительно кастумно.
Наверное чисто серверным программистом, MIGX и TV поля экономят много времени. Но на самом деле тот-же knockoujs можно освоить за пару месяцев в свободное время от работы, и больше не парится по поводу интерфейсов.
Насчет кровавого энтерпрайза. Сюда можно включить такие вещи как CRM системы RESTful сервисы, хранилища данных с большим количеством таблиц и сложной логикой (Банковские сервсы к примеру, Каталог фильмов с расширенной фильтрацией) вот мне сложно представляется как это сделать на MODX.
Что касается сайтов типа лендинг, блог или микро магазин то MODX это самое то, в такого рода проектах большая часть работы это дизайн, верстка и контент здесь программисты не нужны.
Не в коем случаи не имею в виду что в MODX собществе нет программистов, они есть как правило именно они и пишут все компоненты и прочии плюшки, не знаю что их побуждает работать с MODX наверное привычка.
Как CMS MODX превосходен если хоть немного уметь кодить, но если уметь хорошо кодить то на кой вообще нужны CMS все можно и так на сделать.
P.S.
Кстате вот еще насчет интерфейсов, по практике могу сказать, что для подновляющего числа заказчиков интерфейс MODX похож на пульт управления космическим кораблем, особенно это касается пресловутого дерево ресурсов. Так что чем проще интерфейс тем довольней заказчик, исключениям являются самопалкины-кавырялкины вот они любят когда много всяких настроек, когда можно что то сделать без привлечения спеца. Вот по этой причине мне и нравится крававый-энтерпрайз, там без спецов вообще не чего не делается, а контент менеджерам дается до чертиков простой интерфейс что бы не чего сломать не смогли...))
Игорь Сухинин 01.07.2015 22:13 #
Спасибо за обстоятельный ответ :) Такие мнения очень интересно и полезно узнавать. Итак, продолжим :)
>> лет этак 5 тому назад UI часть была проблемой, но не сейчас, что мешает использовать следующие решения для интерфесов
На самом деле здесь Вы, вероятно, меня не совсем правильно поняли. Речь не идет о «красивостях» вроде кнопок с переливающимся фоном (ну как вот сразу под этой формой). Можно взять и просто Twitter Bootstrap тогда… ну или сотни других подобных фреймворков.
Я имел ввиду больше конечную логику построения таких интерфейсов, взаимосвязи между элементами меню, разделами, выпадающими списками и т.п. С возрастающей сложностью сайта растет естественным образом и сложность управляющих систем. Для самых простых сайтов можно обойтись десятком полей ввода, ну так на то это и примитивный проект.
>> Насчет кровавого энтерпрайза. Сюда можно включить такие вещи как CRM системы RESTful сервисы, хранилища данных с большим количеством таблиц и сложной логикой
Это отличные примеры действительно комплексных больших систем. Но причем здесь MODX? Если программисту (обычно команде программистов) доверили разработку системы такого уровня, а он выбрал MODX в качестве базы… ну, беда тогда, что тут еще скажешь :) Я бы посочувствовал этому заказчику.
Поэтому возвращаемся к тому, какую все же нишу занимает MODX. Как я уже писал, с моей точки зрения это малые и средние сайты (хоть и это также расплывчатое понятие). Это такие сайты, где разработка CMS с нуля — экономически неоправданное занятие, однако все же требуется нечто большее и удобное, чем 10 полей в HTML и (возможно) WYSIWYG редактор.
>> для подновляющего числа заказчиков интерфейс MODX похож на пульт управления космическим кораблем
Вы знаете, я удивлен. Мне также приходилось объяснять какие-то детали работы с MODX заказчикам разного уровня технической подготовки, но прямо вот таких проблем не замечал. Очень быстро (порой даже интуитивно) люди понимают, что вот это слева — разделы сайта, здесь нажал на + и открылись подразделы, здесь редактируем контент, а тут — дополнительные поля… И т.д.
Более того, я Вам скажу, что очень многое зависит даже не столько от интерфейса MODX (который стандартен и меняется только от версии к версии), а от того, как мыслит и создает дополнительный интерфейс (расположение TV, дополнительные модули и т.п.) программист, реализующий сайт на MODX.
По роду деятельности я работал и работаю с многими программистами разного уровня подготовки и опыта, в том числе с внештатными исполнителями. И порой мне попадались «поделки» на MODX такого страшного вида изнутри, что я просто сам с наскока не мог разобраться, КАК «оно» работает по логике этого программиста, ибо все было запутано, перемешано и вообще тихий ужас, короче. Ну а уж как это все тормозило во фронтенде… В общем, даже модэкс модэксу — рознь.
>> по этой причине мне и нравится крававый-энтерпрайз
Ну, я как программист поддерживаю Вас :) Мне тоже очень нравятся задачи сложного уровня, заставляющие мозги кипеть, а пальцы дымиться ))) Однако уровень задач бывает разным. И чаще в силу естественных причин задачи поступают более простые, которые также требуют более простых решений. И в данном случае MODX — один из отличных вариантов.
Алексей Александрович 02.07.2015 00:27 #
И спасибо администрации за то что еще не выгнали, а то я в одном сообществе MODX называть не буду, поднял эту тему тут-же забанили.
Считаю что могу говорить на эту тему путь даже это немного критично, я не случайный прохожий, все таки три года отдал данной CMF/CMS в любом случаи она осталась в моей жизни, как и старые заказчики)))
А теперь по существу вопроса.
По первому пункту:
На самом деле в MODX нет не какой сложной логики интерфейса, MODX админка не singl aplication, в то время как приведенные мной инструменты позволяют построить такое переложения в сравнительно короткие сроки. Так что здесь довольно спорный вопрос, половину того что есть в MODX интерфейсе логичнее было бы вынести в конфигурационные файлы, к примеру это config, описание шаблонов и ТВ полей, по крайне мере это позволило бы коментить все это git. А конечным пользователям, аля владелицам салона красаты они и так не к чему.
По второму пункту:
тут без комментариев, добавить если только немного сочувствия)))
А что касается простых сайтов, так что мешает разработать болванку аля блог/сайт_визитка/магазин и разворачивать его и самое главное это то, что такое решение может быть масштабируемом.
в некоторых фремворках есть решения позволяющии развернуть админ часть в короткое время, при помощи одних только канфигов и это не десять полей а гораздо больше, с выподайками и джоинами. Потом все это пакуется в пакет composer и вуаля следующий такой бложек будет сделать за пару минут...)))
По третьему пункту:
Простой и довольно распростроненный пример.
Имеется в дереве пункты первого уровня, в половине используются шаблон за номером 1 в другой половине используют шаблоны за номером 2. вот проблема одно из двух или объяснять глупой (ку… цы) что это разные каталоги с разной логикой и так далее, или писать плагин для автоматизации процесса.
Бывали случаи даже в моей практике, что соберешь сайт, пройдет пол года возвращаешься по просьбе заказчика что нибудь подправить, и вот тут понимаешь что это уже не тот сайт который ты делал. некоторые заказчики снипеты втыкают прямо в modResource.content дебажить такие чудеса очень весело. И вот тут приходит мысль, чем меньше возможностей у менеджера тем целее сайт.
Не должен менеджер добавлять поля или отрисововать шаблоны, потому как представления о prefect code у него нет. В данном случаи гибкость MODX то-есть возможность решить задачу кучай разных способов в том числе очень простых, аля написал снипет воткнул в тело ресурса и забыл играет злую шутку, потому как в неумелых руках это генератор кастылей.
По четвертому пункту:
MODX хорошо подходит дизайнерам, не большим сайтам где как правило сам владелиц шаманит, но вот для проектов над которыми работает группа разработчиков это не самый лучший выбор. Хотя я знаю таких разработчиков которые пытаются соцсети и CRM писать на MODX. Их заказчикам можно только по сочувствовать, это реально выброшенные деньги на ветер, потому как такой код не поддерживаемый…
Так же MODX хорош для начинающих веб разработчиков, во сновном для верстальщиков, потому как позволяет сконцентрироваться на верстке.
Если так же смотреть на сообщество MODX то по нему не скажишь что здесь прям жизнь кипит, наверное это все-таки что то значит. Хотя может с появлениям третей версии все изменится, аж самому интерестно.
Наконец самое главное
Эта GNU лицензия вообще странно как на этом можно делать коммерческии проекты с уникальным кодом. в то время как тот-же Laravel, knockout и даже bootstrap идет под MIT лицензией.
Заказчику выкладывающему огромную кучу денег, стоит задуматься… Хотя наверное в России это пофиг)))
Игорь Сухинин 02.07.2015 08:22 #
Да пожалуйста :) Критика по делу — это же прекрасно. Вот когда начинают поливать г-ном всё подряд без оснований — такие люди нам не нужны.
>> а то я в одном сообществе MODX называть не буду
Да чего скромничать :) Дважды забаненным быть все равно нельзя.
>> На самом деле в MODX нет не какой сложной логики интерфейса
Ну, я бы так не сказал. Интерфейс MODX, быть может, не супер-пупер, но тем не менее удобство работы с ним разработчики продумали неплохо. Вот однозначно согласен с тем, что улучшений хочется в отношении программной логики — в том числе про конфиги и шаблоны.
>> в некоторых фремворках есть решения позволяющии развернуть админ часть в короткое время
Да, я в курсе. Мы активно работаем как минимум с двумя фреймворками — Yii и Symfony. Но это все же не то. Можно построить красивый, удобный интерфейс CMS на них — это бесспорно, но на это требуется уже больше времени. Необходимо сначала планировать и согласовывать схематично систему управления, а уж потом кодировать. И это порой болезненный, долгий процесс. Но иначе и не бывает со сложными проектами. Только опять же это не является нишей MODX.
>> в половине используются шаблон за номером 1 в другой половине используют шаблоны за номером 2
Именно поэтому мы стараемся в своих проектах минимизировать количество шаблонов. Нередко используется только один шаблон (с точки зрения пользователя) даже на относительно крупных проектах. Хотя да, соглашусь, это не всегда сразу бывает понятно пользователю. Тем не менее, когда демонстрируешь разницу на фронтенде, практически все понимают, о чем идет речь.
>> И вот тут приходит мысль, чем меньше возможностей у менеджера тем целее сайт
Ну, так и есть. Поэтому необходимо ограничивать доступы ролями. Выдавайте своему клиенту несколько логинов, распределенных по ролям. И пусть среди них будет роль Content Manager, у которого урезано все, кроме непосредственно доступа к контентной части.
>> Не должен менеджер добавлять поля или отрисововать шаблоны
Я точно не говорил, что менеджер это должен делать. Опять же смотрите выше про роли пользователей.
>> MODX хорошо подходит дизайнерам, не большим сайтам где как правило сам владелиц шаманит, но вот для проектов над которыми работает группа разработчиков это не самый лучший выбор
На самом деле мы говорим об одном и том же, но разными словами. Проекты с группой пользователей — это обычно БОЛЬШИЕ проекты. Следовательно, с большой долей вероятности здесь потребуются кастомные решения, а не готовая система — будь то MODX или что-то еще.
>> Эта GNU лицензия вообще странно как на этом можно делать коммерческии проекты с уникальным кодом
GNU лицензия MODX распространяется на код MODX, а не на всякие дополнения, которые по сути могут быть под любой лицензией. Иными словами, если Вы берете MODX (не меняя код системы и предоставляя пользователю ее в неизменном виде) и продаете на его основе сайт — это не нарушение лицензии.
А вот если Вы берете MODX и делаете на его основе другую CMS (форк), то Вы обязаны распространять этот код по условиям GNU GPL. Вот как раз на это нередко на пост-советском пространстве плюют — не нужно далеко ходить за примером, совсем недавно развивалась такая история habrahabr.ru/post/257149/.
Алексей Александрович 03.07.2015 03:00 #
Но тогда остается вопрос? как правило программисту вообще админка ненужна с файлами работать проще, а если менеджер не видит лишних настроек то для кого тогда все эти возможности, не понятно.
Но к сожалению в MODX работать с файлами не получится, большая часть того что нужно хранится в базе, эта вообще отдельная история…
насчет лицензии, в том то и дело что форки полноценные нельзя делать а это скучно и не интересно...))
Делаю сейчас проект на ларе со сложной логикой кучай джоинов и прочих отношений, и вот как выглядит база скрин тут по моему и без комментариев понятно о чем сайт настоящий DRY в сравнении с базой MODX.
А вот интерффес на knockoutjs + bootstrap с выподайками, чекбоксами, табами и файловым менеджером.
скрин
скрин
скрин
Выдумаете что это сложно? Нет это не сложно, все описание интерфейса в одном файле только контролеры успевай писать скрин
Вообще не вижу сложностей делать свои интерфейсы. (Кстате когда закончу с проектом, может адаптирую интерфейс под MODX)
Качество кода можно оценить с пустя пол года а то и года. Когда говорят да на MODX можно сделать что угодно, да можно, можно и на чистом PHP сделать но вот только вопрос как долго тот разработчик что придет за тобой будет разбираться в том что написано.
Вообще к чему я это все? Хочу просто оградить в особенности начинающих прогеров(касается только их) пытаться делать соц-сети или крупные-магазы и прочие сервисы на MODX.
У данной прикрасой CMS есть куча плюсов но не стоит выходить за её рамки, так как за границами MODX живут какраз те самые маниакальные психопаты...)))
P.S.
Однажды много лет назад я написал не большой магаз на ShopKpeere, и как я хотел спустя пару лет убить того разработчика который выбрал данную плотформу. Потому как за эти пару лет сайт так мутировал что разобраться что там наколбасили было довольно «весело».
Вот в таких случаях git просто не заминим, делаешь коминт, потом возвращаешься и смотришь прям по строчкам что тут сделали за твоё время отсутствия. Ведь правда классно!!! надеюсь что в третей версии MODX тоже получит такую возможность.
Игорь Сухинин 24.11.2015 09:57 #
Я много выше высказывался в защиту MODX, но в данном случае могу привести также и контр-аргументы :)
>> А вы уверенны что сделали все оптимально и безопасно и расширяемо?
Довольно сложно сделать небезопасно, следуя гайдлайнам и стандартам новейших фреймворков. Это наоборот еще надо потрудиться, чтобы оставить явные бреши в таком сайте :) Расширяемо — это слишком общее понятие, можно в него вкладывать многие вещи. Готовый сайт на MODX не такой уж расширяемый на самом деле.
>> А вы написали документацию как с этим работать?
Документация — это всегда проблема, тут нечего добавить. Но ты знаешь, я столько сталкивался с «чудо-поделками» на MODX разных версий… И да, они работали на «стандартных» сниппетах и модулях. Но при этом у меня мозг вскипал, чтобы отследить, КАК же это работает :) Причем эти чудесные сайты ужасно тормозили с минимальной функциональностью.
>> А что делать клиенту если вы заболели уехали
Если есть какая-никакая документация, используется относительно распространенный фреймворк и код написан плюс-минус стандартизировано, то все не так печально.
>> Вы сильно любите копаться в чужем коде?
Никто не любит, полагаю. Но вот для меня гораздо проще понять, как работает небольшой сниппет, заточенный строго под конкретную задачу, чем осилить 100500 параметров какого-то монстра типа getResources или его предка Ditto. Использование этих монстров — это чаще всего как стрельба из пушек по воробьям. Нет, если знаний в PHP кот наплакал, это будет, возможно, единственным выходом. Но в то же время это ужасно затормаживает работу системы.
>> это позволяет работать быстрее и качественнее
Возможно, для разработки простых сайтов именно процесс самой разработки проходит быстрее… Возможно. При условии, если уже запомнить весь этот список параметров и извращенных вызовов сниппетов в сниппетах, которые сами по себе вызывают еще полтонны чанков и сниппетов… Ну да, только если так. Качественнее — вот тут сильно сомневаюсь. Вопрос, в чем оценивать это качество. Не знаю, может это мне так не везло, но нередко сайты, которые мне попадались по случаю, которые были вот сделаны кем-то на стандартных сниппетах — ужасно тормозили, работали как-то непредсказуемо, а внутри в CMS был какой-то ад в плане интерфейса пользователя, т.к. программисту приходилось подстраиваться под имеющиеся средства, а не создавать их самостоятельно.
Такие вот мои мысли :)
#
Игорь Сухинин 24.11.2015 13:44 #
ProuD 24.11.2015 13:14 #