CMF или framework?
Всем добрый вечер! Хотелось бы услышать мнение опытных разработчиков насчёт MODX — были ли случаи, когда MODX не мог справится с поставленными задачами? Собственно вопрос обозначен в теме. Никак не могу определиться на чем же все-таки писать проект. Вроде бы модули там должны быть относительно простые: личный кабинет, история заявок, калькулятор, обмен данными (по API с CRM). Но есть сомнения, что есть смысл использовать MODX учитывая, что все эти модули надо будет писать — готовых нет.
Комментарии: 25
С вашими задачами справиться легко. У modx есть много дополнений, возможно все писать не придется, ЛК есть готовый классический модуль… по всем остальным задачам, вряд ли что то есть готовое для других систем, так что разницы нет на какой системе, писать все равно придется.
Думаю, учитывая возможности кастомизации и тот факт, что MODX как раз и предназначен для лёгкого внедрения своего кода, выбор очевиден.
Другой вопрос, достаточно ли хорошо вы знаете MODX.
Другой вопрос, достаточно ли хорошо вы знаете MODX.
Знание решает, все верно!
Да и не понятно мне, зачем задавать такой вопрос в сообществе MODX. Явно же, что местные будут хвалить «своё болото».
Если хотите писать много кода и изобретать велосипед, который в MODX уже изобрели и на котором успешно катаются (система юзеров, групп, ресурсы и т.д.), то смотрите в сторону фреймворка.
Да и не понятно мне, зачем задавать такой вопрос в сообществе MODX. Явно же, что местные будут хвалить «своё болото».
Если хотите писать много кода и изобретать велосипед, который в MODX уже изобрели и на котором успешно катаются (система юзеров, групп, ресурсы и т.д.), то смотрите в сторону фреймворка.
Полностью согласен с мнением Павла. В общем и целом, думаю так же, как написано во втором абзаце, когда задумываюсь о Laravel и иже с ним.
Везде есть свои преимущества и недостатки.
Везде есть свои преимущества и недостатки.
Миш, позволю себе не согласится с твоим мнением про много кода и велосипеды при программировании в Laravel. Для него/неё написано гораздо больше модулей, чем для MODX. Главный недостаток — это отсутствие UI во многих из них. Но на то он и framework. :) Лично у меня после того, как я преодолев страх погрузился в Laravel, не возникает ни малейшего желания возвращаться на MODX. А страх был именно из-за отсутствия привычного UI. Пользователи Windows меня поймут — линуксы, юниксы и баши до сих пор вызывают у меня дрожь. :)
Прекрасно понимаю все то, о чем говоришь.
Но речь в комментарии Павла была о том, что в MODX это все есть «из коробки» и все дополнительные модули работают именно с этими системными объектами, а не дополнительно поставленными.
Если в Laravel все стандартизировано — хорошо. В этом я могу ошибаться, ибо не погружался.
Но речь в комментарии Павла была о том, что в MODX это все есть «из коробки» и все дополнительные модули работают именно с этими системными объектами, а не дополнительно поставленными.
Если в Laravel все стандартизировано — хорошо. В этом я могу ошибаться, ибо не погружался.
Ну если говорить про
личный кабинет, история заявок, калькулятор, обмен данными (по API с CRM)то этого ничего нет «из коробки». Всё придется ставить дополнительно или писать самому.
Если в Laravel все стандартизировано — хорошо.Иначе он работать не будет. Как и любой другой фреймворк. Причем он поддерживает все последние стандарты в отличие от MODX. А последний уже морально устарел. Именно поэтому кривая его популярности ползёт вниз. А MODX 3 так и не родился, хотя ждали больше 3-х лет.
Если в Laravel все стандартизировано — хорошо.Иначе он работать не будет. Как и любой другой фреймворк.
Имел ввиду другое — нет ли в нем ситуации, когда для пользователей, к примеру, несколько разных модулей с не полностью совместимыми между собой реализациями, а совсем другие модули работают только с какой-то определенной реализацией пользователей?
Самый простой пример в MODX — minishop2 с его кучей дополнений и Shopkeeper, под который тоже, вроде, можно что-то делать, но фактически очень мало что есть.
Laravel построен по принципу SOLID и опытный разработчик следует этому принципу при разработке приложений на ларе. Как правило, один модуль ничего не знает про другой. Зависимости реализованы через абстракции. К примеру, личный кабинет. Чтобы он работал, класс пользователя должен инмплементировать соответствующий интерфейс с требуемыми методами. Таким образом, в разных проектах объект пользователя может отличаться полями, но содержит всегда требуемые методы. Это открывает большие возможности — легко расширять функционал, проще тестировать. Это чисто для примера. Менеджеру, привыкшему просто загружать пакет из менеджера пакетов MODX, объяснить это непросто, но программист поймёт о чём я говорю. Это реально другой уровень. Сам я ещё не все прелести попробовал, но от уже познанного в таком восторге. :)
Звучит интересно, конечно :)
Уже второй человек, которого я знаю кто после MODX перешел на Laravel)
А по какому принципу выбирали? Я тут просто подумываю про yii2, потому что документация хорошая есть на русском.
А по какому принципу выбирали? Я тут просто подумываю про yii2, потому что документация хорошая есть на русском.
А кто первый? )
Я знаю несколько человек из сообщества MODX, кто работает на Laravel, и ни одного, кто знает yii2. Возможно это повлияло.
Эти два фреймворка приблизительно похожи. Смотрел и тот и другой. Почему-то решил выбрать Laravel. У последнего и документация хорошая и сообщество живое. Да и популярность Laravel стремительно растет. Моё мнение, выбрав один из этих фреймворков ошибиться нельзя.
P.S. Как выбрать PHP фрейворк.
Я знаю несколько человек из сообщества MODX, кто работает на Laravel, и ни одного, кто знает yii2. Возможно это повлияло.
Эти два фреймворка приблизительно похожи. Смотрел и тот и другой. Почему-то решил выбрать Laravel. У последнего и документация хорошая и сообщество живое. Да и популярность Laravel стремительно растет. Моё мнение, выбрав один из этих фреймворков ошибиться нельзя.
P.S. Как выбрать PHP фрейворк.
Вот — modx.pro/users/93/ :)
Вот только подумала, что определилась и вот опять в раздумьях…
Вот только подумала, что определилась и вот опять в раздумьях…
Я же говорю, тут нет смысла холиварить — оба достойные варианта, тут ошибиться нельзя. Вот для сравнения.
Есть ещё фреймворк Lumen, который является младшим братом Laravel. Он используется для сервисов и API. Он почти мгновенно отдает ответ на запрос, потому что не грузит все эти тонны классов, как это делает Laravel. Т.е. в багаже разработчика Laravel уже 2 инструмента. Не знаю, есть ли такое для yii2.
Кстати, ещё Lumen часто используют для SPA приложений (одностраничных) на ангуляре или вью. Что тоже сейчас очень популярно.
Есть ещё фреймворк Lumen, который является младшим братом Laravel. Он используется для сервисов и API. Он почти мгновенно отдает ответ на запрос, потому что не грузит все эти тонны классов, как это делает Laravel. Т.е. в багаже разработчика Laravel уже 2 инструмента. Не знаю, есть ли такое для yii2.
Кстати, ещё Lumen часто используют для SPA приложений (одностраничных) на ангуляре или вью. Что тоже сейчас очень популярно.
Так я же сама в это «болоте» и нахожусь)
Хотела услышать мнение опытных разработчиков сталкивались ли они с какими-то задачами, с которыми возможностей MODX было мало. Ну вдруг такие есть…
Хотела услышать мнение опытных разработчиков сталкивались ли они с какими-то задачами, с которыми возможностей MODX было мало. Ну вдруг такие есть…
На всякий случай — modhost.pro и modstore.pro сделаны полностью на MODX, с использованием стандартных Office, miniShop2 и других дополнений.
При этом там очень удачно интегрирован и свой уникальный функционал Так что, никаких препятствий для использования MODX в качестве фреймворка я не вижу.
При этом там очень удачно интегрирован и свой уникальный функционал Так что, никаких препятствий для использования MODX в качестве фреймворка я не вижу.
А вот этот свой уникальный функционал как отдельные модули сделан? Т.е. и Office и miniShop2 можно без проблем обновлять?
Большое спасибо!
Подскажи, пожалуйста, есть ли какое-то ограничение по одновременной работе в системе MODX? Что в бОльшей степени влияет на это? То, как написан используемый для этого модуль (имеются в виду авторизованные пользователи), сервер, на котором располагается система или что-то еще?
Можно я отвечу?)
Насколько я знаю, в MODX совместная работа реализована только с ресурсами. То есть одновременно два зашедших в документ не смогут сохранить разные варианты.
А с элементами (чанки, сниппеты, плагины) и уж тем более компонентами такого по умолчанию нет. Выходит, что и ограничений никаких нет. И многие, кто давно работают с MODX, стараются отойти от разработки сайта в самой системе. То есть пишут модули, сниппеты, чанки в своей любимой IDE, например в PhpStorm.
И уже благодаря такому методу, для совместной разработки используются инструменты для совместной работы Git (GitHub, BitBucket и т.д.).
Насколько я знаю, в MODX совместная работа реализована только с ресурсами. То есть одновременно два зашедших в документ не смогут сохранить разные варианты.
А с элементами (чанки, сниппеты, плагины) и уж тем более компонентами такого по умолчанию нет. Выходит, что и ограничений никаких нет. И многие, кто давно работают с MODX, стараются отойти от разработки сайта в самой системе. То есть пишут модули, сниппеты, чанки в своей любимой IDE, например в PhpStorm.
И уже благодаря такому методу, для совместной разработки используются инструменты для совместной работы Git (GitHub, BitBucket и т.д.).
Конечно)) Спасибо!
Правда не особо понятно что значит «стараются отойти от разработки сайта в самой системе. То есть пишут модули, сниппеты, чанки в своей любимой IDE, например в PhpStorm.»
В конечном итоге разве все разработки не попадают в систему? Или я не так задала вопрос.
Вопрос в том, сколько в итоге пользователей системы смогут работать в ней при одновременной авторизации (уже после того как система будет написана)?
Правда не особо понятно что значит «стараются отойти от разработки сайта в самой системе. То есть пишут модули, сниппеты, чанки в своей любимой IDE, например в PhpStorm.»
В конечном итоге разве все разработки не попадают в систему? Или я не так задала вопрос.
Вопрос в том, сколько в итоге пользователей системы смогут работать в ней при одновременной авторизации (уже после того как система будет написана)?
В конечном итоге разве все разработки не попадают в систему?
Устанавливаются как транспортные пакеты) кто-то так даже контент добавляет.
Всё это время я имел ввиду админку.
Но если вопрос всё же про количество пользователей обычных на фронте, то да, ограничения немного есть и зависят от процессоров/оперативной памяти и даже от размера диска или базы данных.
При большом количестве пользователей разрастается база данных из-за сессий, при малой свободной памяти можно уткнуться в ограничение, но они могут автоматически очищаться.
Василий где-то уже объяснял про процессоры на хостинге, сколько одновременно клиентов обслуживается.
И по авторизации никаких ограничений нет (разве что размер памяти), хоть все пользователи, например на modx.pro (~5к человек), могут быть авторизованы, ничего страшного не произойдёт.
Тут лучше наоборот, предложить сколько клиентов одновременно будет находиться на сайте и исходя из этого попытаться рассчитать возможную нагрузку на хостинг/сервер.
Но всегда же можно увеличивать мощность, оптимизировать код, когда проект набирает обороты)
В данном случае всё зависит от железа. Про какие-то ограничения с пользователями я не слышал, а вот с ресурсами была такая проблема. На хабре была статья Николая Ланца про это. По моему свыше 300 тыс. ресурсов MODX уже обработать не может. Нужно отключать кэширование карты алиасов и чего-то там ещё. В общем выкручиваться.
Для настолько больших сайтов правильнее сразу отказаться от ресурсов, как на vrmedia.ru (точный адрес не помню), о котором писал Василий.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.