phdru.name / Russian / Software

why_not_zope.html

За что мне не нравится Zope.

Zope - это сервер web-приложений, предназначенный для разработки и создания систем управления контентом (CMS, content management systems). CMF и Plone, и порталы, сделанные с их помощью - самые характерные примеры.

Приложения, которые в нём могут исполняться, я охарактеризую так: некритичные web-приложения среднего объёма, рассчитанные на команду из 2-3 программистов и 1-2 верстальщиков.

В Zope простые вещи делаются сложно, а сложные - невозможно.

Основные объекты, с которыми манипулирует Zope - экземпляры классов, написанных в соответствии с Product API. Эти объекты, в сущности, есть наборы простых стандартных атрибутов, с простым графом состояний. Для многих задач такая модель совершенно неадекватна.

Для компонентов совершенно отсутствует upgrade path, в результате чего модернизация Zope и/или отдельных компонентов превращается в игру "русская рулетка", вплоть до полной потери данных, если в документации на новую версию компонента сказано "перед установкой новой версии вы должны удалить все экземпляры предыдущей версии, а после установки создать их заново." Или, скажем, какой-нибудь компонент просто перестаёт работать в следующей версии Zope.

Zope - это большая куча не вполне питоновского кода. Читать его мучительно, понимать тяжело, хакать сложно, хотя и обязательно.

Обещано, что Zope состоит из компонент, но это неправда. Из всех компонент из Zope без проблем удаётся вытащить лишь ZODB. Остальные компоненты слишком много знают друг про друга, и для использования их вне Zope их приходится вытаскивать вместе с половиной других компонент. Да и стоит ли их вытаскивать? ZPublisher, например, содержит в себе столько "крючков" для зацепления Zope, что отдельно не используется. Из всех компонент отдельно используется разве что ZPT, да и то для его использования требуется отдельный продукт StandaloneTAL.

Security API в Zope странно устроено и плохо документировано (отдельный вопрос - а что в Zope хорошо документировано?). К тому же есть несколько разных версий этого API, в результате чего в одном приложении могут столкнуться компоненты, использующие разные механизмы безопасности. Это ставит безопасность приложений Zope под большой вопрос.

Zope устанавливается со включённой защитой в таких местах, где она далеко не всегда нужна, причём не хакая код эту защиту и не выключить. Эта защита хороша для создания порталов, на которых всякие ламеры могут создавать свои шаблоны, но совершенно не годится для интранет-серверов и многих других задач.

С другой стороны, если Zope предназанчен для порталов, то почему нельзя загрузить файлы экспорта (zexp), не имея доступа к файловой системе самого сервера? Приходится давать пользователям доступ к директории import, позволять видеть чужие файлы, или ставить всякие допольнительные web-импорты, безопасность которых под большим вопросом.

Эти ужасные Z-Классы. Вы когда-нибудь пробовали изменить список родительских классов Z-Класса? А не top-level Z-Класса?

Этот чудовищный ZSQL. Чудовищностью его я окончательно проникся, когда переносил сайт с PostgreSQL на MySQL (неважно... это могли бы быть SAP DB и Firebird). Перенос потребовал полного уничтожения всех ZSQL-коннекций, а при создании новых оказалось, что все ZSQL-методы хранят ссылки на старые коннекции. Пришлось пересоздавать и все ZSQL-методы. Вместо всей этой фигни в Zope должно было бы быть нормальное объектно-реляционное отображение. Но нету.

Половину исходников Zope держит в файловой системе, причём в разных местах (код Продуктов, код External Methods), половину в ZODB (шаблоны, ZSQL-методы, Z-Классы). В результате не работают все богатые средства командной строки - find/grep/cvs...

Постоянные проблемы с кодировками. В каждой версии Zope какие-нибудь свои особенности работы с кодировками. Авторы Zope этих проблем не понимают и соответствующие патчи принимать отказываются.

Шаблоны DTML - самые неподобающие шаблоны в мире. Они эмулируют часть функциональности Питона, и требуют скоординированной работы над шаблоном программиста и верстальщика. Лучше было бы включить в Zope что-то типа Python Server Pages, в которых код на чистом Питоне перемежался бы с кодом на чистом HTML. ZPT - это тоже не совсем то, хотя и чуть лучше DTML; шаблоны ZPT хотя бы в большей степени ориентированы на верстальщика.

Bogdan Maryniuk <bogdan.maryniuk@gmail.com> написал про Zope3: "Он будет еще сырым год, как минимум. Если не больше.

А когда его сделают, то только фанаты и будут его использовать: это медленное полуконфигуративное творение оверенджиниринга с его медленным zcml вообще мало кто из реальных программистов захочет использовать. Кто захочет изучать иронически "Easy framework"; easy настолько, что невозможно все эти "легкости" уложить в голове от их количества?"

Ссылки по теме:

http://www.amk.ca/python/writing/why-not-zope.html

http://pywx.idyll.org/advocacy/why-not-zope.html

http://pywx.idyll.org/advocacy/why-not-zope-2.html

http://zope-is-evil-666.idyll.org/


Эта страница https://phdru.name/Russian/Software/why_not_zope.html была сгенерирована 14.07.2021 в 00:38:07 из шаблона CheetahTemplate why_not_zope.tmpl; Некоторые права зарезервированы. Вы можете узнать о технических аспектах этого сайта.