Comments 10
Список недостатков полностью убивает список достоинств. Единственный плюс — призрачная безопасность. Хм…
Если проблемы с производительностью решаются неплохо: кеши, кеш блоки, промежуточное кеширование, esi и тд, то быстро что-то починить когда упало, без знания системы, наверное не получится. Необходимо сперва будет проникнуться духом фреймворка.
> Все еще интересно?
Уже нет, спасибо.
Не понимаю зачем тратить дорогое (как правило) время программистов на изучение вещи, которая в любой момент может перестать работать и причину этого найти нереально. Учить отдельный язык программирования шаблонов. Не проще взять фреймворк и написать что нужно?
Уже нет, спасибо.
Не понимаю зачем тратить дорогое (как правило) время программистов на изучение вещи, которая в любой момент может перестать работать и причину этого найти нереально. Учить отдельный язык программирования шаблонов. Не проще взять фреймворк и написать что нужно?
Просто так оно не перестанет работать. Оно иногда перестает выполнять свои функции, например когда модуль отвалился, или верстка поплыла, из-за небрежного отношения или невнимательности.
— Не проще взять фреймворк и написать что нужно?
Ну это и есть такой фреймворк, содержащий базис функционала, на осонове которого можно доделать нужное. Функционала и поправде очень много, помню выпускались книги, для страждущих.
— Не проще взять фреймворк и написать что нужно?
Ну это и есть такой фреймворк, содержащий базис функционала, на осонове которого можно доделать нужное. Функционала и поправде очень много, помню выпускались книги, для страждущих.
В русскоязычном сообществе ezPublish когда-то очень правильно подметили: «Это как боинг, только разобранный на части. Вроде и круто, но совершенно не понятно, как все это собирать и столь же дорого в обслуживании».
Проработав уж два года с данной системой я вынужден согласиться. Во-первых она безумно тормозит (частично это решается выкидыванием апача и связкой nginx+varnish), поэтому постоянно приходится обвязывать кучей кешей, причем до такой степени, что полная очистка кеша через админку попросту приведет к смерти сайта на пару часов, в результате приходится искать и удалять кеш руками через фтп/шелл.
Да, она гибкая и очень функциональная, ровно до тех пор, пока не нужно сделать шаг влево.
А уж если изначально сайт на системе делал кто-нибудь другой, то можно быть уверенным, что нужную настройку вы не найдете днем с огнем.
И еще, в целях сохранения рассудка, никогда не используйте модули от lagarder (хотя их там в паблике вроде не так много).
Проработав уж два года с данной системой я вынужден согласиться. Во-первых она безумно тормозит (частично это решается выкидыванием апача и связкой nginx+varnish), поэтому постоянно приходится обвязывать кучей кешей, причем до такой степени, что полная очистка кеша через админку попросту приведет к смерти сайта на пару часов, в результате приходится искать и удалять кеш руками через фтп/шелл.
Да, она гибкая и очень функциональная, ровно до тех пор, пока не нужно сделать шаг влево.
А уж если изначально сайт на системе делал кто-нибудь другой, то можно быть уверенным, что нужную настройку вы не найдете днем с огнем.
И еще, в целях сохранения рассудка, никогда не используйте модули от lagarder (хотя их там в паблике вроде не так много).
-Это как боинг, только разобранный на части.
Да, но этот инструментарий позволяет собрать не только боинг, но что-то поменьше, удобнее.
-но совершенно не понятно, как все это собирать
Делается все возможное, чтобы упростить работу. Например создали давно ezwebin расширение, которое содержит в себе базовые шаблоны и функционал, позволяющие не париться и быстро поднять сайт.
-Во-первых она безумно тормозит
Самое узкое место, это шаблонный парсер. Запросы не особо напрягают, даже большие сайты, например с 2млн объектами в дереве контента и много тыщ зарегестрированных пользователей, работают и достаточно эффективно.
Т.е. если работать с кешированными шаблонами и часть специального функционала писать самому ввиде модулей и пр, то особо тормознутость не напрягает.
-полная очистка кеша через админку попросту приведет к смерти сайта на пару часов
Это бывает, но в реальности чистить полностью кеш не особо надо. Достаточно контент кеш или темплайт кеш. Хотя при «правильной» реализации, чистить кеш и вовсе не требуется, за это беспокоится сам Изи Паблиш. Например добавил объект, кеши для него почистились.
Что касается изменения дизайна, то конечно кеш чистить нужно, благо это происходит нечасто и соответственно не весь кеш должен быть почищен.
-она гибкая и очень функциональная, ровно до тех пор, пока не нужно сделать шаг влево.
Нужно всегда считаться с инструментарием, если он не годится, стоит пойти более выгодным путем.
-А уж если изначально сайт на системе делал кто-нибудь другой, то нужную настройку вы не найдете днем с огнем.
Есть такое. Когда разработчики хотели создать еще одну настройку в ини файле, то главный техрайтер сказал
— One more fucking setting
Конечно это неудобно, когда так много настроек, но они редко конфликтуют, и не стоит много беспокоится, главное знать где и как их отыскать.
Поэтому стоит быть немного дисциплинированным во время создания решения. Примеров, когда сторонний екстенсион ломал что-то, очень много, просто рекомендация, использовать от вендора или проверенных авторов.
Да, но этот инструментарий позволяет собрать не только боинг, но что-то поменьше, удобнее.
-но совершенно не понятно, как все это собирать
Делается все возможное, чтобы упростить работу. Например создали давно ezwebin расширение, которое содержит в себе базовые шаблоны и функционал, позволяющие не париться и быстро поднять сайт.
-Во-первых она безумно тормозит
Самое узкое место, это шаблонный парсер. Запросы не особо напрягают, даже большие сайты, например с 2млн объектами в дереве контента и много тыщ зарегестрированных пользователей, работают и достаточно эффективно.
Т.е. если работать с кешированными шаблонами и часть специального функционала писать самому ввиде модулей и пр, то особо тормознутость не напрягает.
-полная очистка кеша через админку попросту приведет к смерти сайта на пару часов
Это бывает, но в реальности чистить полностью кеш не особо надо. Достаточно контент кеш или темплайт кеш. Хотя при «правильной» реализации, чистить кеш и вовсе не требуется, за это беспокоится сам Изи Паблиш. Например добавил объект, кеши для него почистились.
Что касается изменения дизайна, то конечно кеш чистить нужно, благо это происходит нечасто и соответственно не весь кеш должен быть почищен.
-она гибкая и очень функциональная, ровно до тех пор, пока не нужно сделать шаг влево.
Нужно всегда считаться с инструментарием, если он не годится, стоит пойти более выгодным путем.
-А уж если изначально сайт на системе делал кто-нибудь другой, то нужную настройку вы не найдете днем с огнем.
Есть такое. Когда разработчики хотели создать еще одну настройку в ини файле, то главный техрайтер сказал
— One more fucking setting
Конечно это неудобно, когда так много настроек, но они редко конфликтуют, и не стоит много беспокоится, главное знать где и как их отыскать.
Поэтому стоит быть немного дисциплинированным во время создания решения. Примеров, когда сторонний екстенсион ломал что-то, очень много, просто рекомендация, использовать от вендора или проверенных авторов.
У нас весьма крупный сайт, который изначально делался французами. С кучей их же экстеншнов, разработчики которых давно поувольнялись. Дизайн модифицировать приходится весьма часто. И узким местом является именно база, потому как все остальное кешируется в статику и отдается акамеем.
И все равно, при том, что оно дополнительно обвешано мемкешедом, блочным кешированием через esi:include и акамеем, оно не выдерживает текущую нагрузку.
К сожалению инструментарий выбирали не мы, иначе бы уже давно выкинули бы все это к чертям.
И единственный на данный момент адекватный вариант заставить все это работать адекватно — переносить все к себе, отказываться от половины решений французской стороны и делать по-своему.
И все равно, при том, что оно дополнительно обвешано мемкешедом, блочным кешированием через esi:include и акамеем, оно не выдерживает текущую нагрузку.
К сожалению инструментарий выбирали не мы, иначе бы уже давно выкинули бы все это к чертям.
И единственный на данный момент адекватный вариант заставить все это работать адекватно — переносить все к себе, отказываться от половины решений французской стороны и делать по-своему.
Я предполагаю, что много стороннего функционала, которое работает с базой. Возможно действительно лучший вариант, переписать, в том числе и архитектуру, если конечно пофиксить не удается. Можно посмотреть в сторону мастер слейв архитектуры, инсерты в мастер, селекты в слейв. Если уж даже со статикой трудности.
Sign up to leave a comment.
Введение в eZ Publish на примере создания сайта