Уже давно я защищаю использование Zope библиотек в Pyramid.
Я провожу больше времени, чем бы мне хотелось, отвечая на подобного рода вопросы в IRC канале #pyramid на Freenode:
<некто> я слышал что пирамида использует zope. zope это плохо.
почему пирамида основана на zope?
Год: 1999. Место: контора по программному обеспечению в Филадельфии штат Пенсильвания, США. Двадцать-с-чем-то разработчик программного обеспечения с не большим опытом программирования, необходимо написать интранет-приложение для местной энергетической компании. Он очень зеленый. Он вначале пути. Он знает Perl достаточно, чтобы быть невероятно опасным. Он начинает писать систему на Perl используя MySQL в качестве бекенда. Каждая функция в системе выглядит примерно так:
sub get_domains {
my $r = Apache::Request->new(shift);
my %cookiejar = Apache::Cookie->new($r)->parse;
#... проверить куки на наличие идентификатора пользователя ...
# ... проверить идентификатор пользователя в таблице в базе данных,
# ... что покажет может ли вызывающий пользователь получить дданные
# ... если нет, то перенаправление на страницу входа в систему.
# ... если да, то некоторые непостижимые SQL чтобы получить данные
# ... и отобразить их в HTML.
}
Процесс идет сложно. В интернете в пятницу после обеда, в муках девелопящий то, что должно стать mod_perl clusterfuck эпических пропорций, разработчик видит на Slashdot, что новая система по имени Zope 1.10, написанная на конкурирующем языке сценариев Python, была выложена в открытый доступ. Он рекламирует себя как "сервер приложений", а скриншоты показывают прикольные административные страницы, связанные с безопасностью. Он решает попробовать его. Он загружает установщик на свой компьютер Windows NT, устанавливает его двойным щелчком, и следует некоторым очень простым инструкциям, чтобы увидеть его административный интерфейс в своем браузере Netscape Navigator 4. Он сразу поражен тремя вещами: а) вы можете написать код, используя веб-браузер, б) его модель безопасности очень продвинутая, так что вы даже можете позволить ненадежным людям писать код, используя веб-браузер и в) определение безопасности в Zope является декларативным, что означает, что все шаблонные проверки безопасности которые он делал в своём mod_perl приложении могут уйти, если он купится на его модель безопасности и данных. Ему даже не нужно использовать отдельную реляционную базу данных, он имеет свою встроенную объектную базу данных. Встроенный интерфейс позволяет ему увидеть графическое представление как данных в базе данных, так и кода, в виде дерева. Это удивительное для него откровение, и он знает, что он может написать своё приложение намного быстрее и намного легче, если он воспользуется особенности что дает ему эта система. Нет ничего из существующего похожего на это, что может сделать кого-то с его профессиональным уровенем настолько продуктивным.
Таким образом, он рискует. Он выбрасывает свой mod_perl код.Совсем не зная Python, черпая информацию из исходников Zope и случайных дискуссий в рассылкуе , он получает очень простую интранет систему с использованием Zope. Он ничего не знает вообще о написании тестов, и никто в его компании не придает значение тестированию , так что он не пишет их. И, несмотря на через-веб-броузер кодирование, и, несмотря на незнание Python перед началом работы, то, что у него выходит получается чище, чем то, что он мог бы получить с mod_perl, если бы вообще получил, потому что а) он может полагаться на декларативную систему безопасности в Zope, б) существует пользовательский интерфейс, на который он может просто указать заказчику, если ему нужно изменить безопасность и другие параметры и в) система имеет гораздо более детальную модель безопасности, чем все, что он мог бы придумать сам; система безопасности контекстно-зависимая, так что если кто-то добавляет документ к интранету, сам документ может выполнять свои собственные настройки доступа без особых проблем. Он представляет результат Заказчику, они счастливы и они платят. Когда новая версия Zope, версия 2.0, выпущена очень короткое время спустя, он портирует код на неё с относительной легкостью.
Он делает еще несколько работ на Zope, но он попадает в немилость у компании из Филадельфии, потому что они хотят сосредоточиться на продуктах Microsoft. Впоследствии, он посредством некоторого космического волшебства оказывается работающим в Digital Creations, являющихся создателями Zope. Жизнь хороша в течение нескольких лет. Он пишет Zope 2 приложения для различных клиентов и учится у своих (гораздо, гораздо более опытных) коллег и руководителей из Digital Creations, что из себя представляет настоящая разработка программного обеспечения.
За эти годы, однако, разработчик из Филадельфии замечает несколько вещей в индустрии разработки программного обеспечения. Он замечает, что, если она принимает некоторые технологии временно, она будет терпеть вещи, которые немного отличаются, но она всегда воротит нос, делая так и всегда будет отступить назад к знакомым технологиям при первой же возможности. Промышленность относится подозрительно ко всем базам данных, которые не являются реляционными. В частности, весьма подозрительно относится к объектным базам данных, из-за того что оказалось чреземерно раздутым вокруг Smalltalk в конце 80-х и начале 90-х. Ей также не нравятся вещи, с плохой документации, отмечает он.
Некоторые субоптимальные вещи в Zope также стали очевидны для него. Становится ясно, что самой Zope необходимо автоматизированное тестирование, потому что люди с разным уровнем умения (включая его) добавляют сомнительные вещи с головокружительной скоростью без особого контроля качества, и оно страдает в результате. Также становится ясно, что модель программирования "через веб", которой был так очарован разработчик из Филадельфии, имеет много недостатков. Очень трудно писать автоматизированные тесты для кода, написанного таким образом. И поскольку, модель “через веб” так глубоко укоренилась в системе, она на самом деле делает написание кода, который не хочет заботиться о “через-веб-броузер” модели, гораздо сложнее. Само существование модели безопасности “через-веб” и ожиданий пользователей об административном интерфейсе делает написание более продвинутго кода муторным. Это само загнало себя несколько в угол, потому что именно то, что привлекало новых пользователей в Zope, как правило, отталктвало их после первоначальных успехов с системой. Для того, чтобы написать код покрытый тестами, инженеры из Digital Creations не могут использовать модель разработки “через-веб”, но писать не “через-веб” код в Zope это своего рода заноза в заднице. Становится очевидным, что либо модель разработки “через-веб” должна умереть или, что гораздо, гораздо лучшие инструменты должны быть разработаны, чтобы поддержать её. Однако, никто не имеет времени, чтобы написать значительно лучше, чем набор инструментов, которые уже есть в UNIX. Разочарование в модели разработки ощущается внутри и за пределами компании.
Несмотря на все это, Zope вполне успешнен в 2001 году. Он выигрывает "Jolt Product Excellence Award" от Software Development Magazine в 2001 г. (с текстом награды ... "продукт, который выиграл "тряхнул" отрасль с их значимой и без того сложной задачей создания корпоративного ПО быстрее, проще и более эффективной ") и показан на обложке этого журнала. Крупнейшие медиа-корпорации запускают сайты, построенные на платформе;. она идеально подходит для них, и Digital Creations пользуется немалым консалтинговым успехом, становится все более прибыльным. Основная рассылка Zope получает около 100 сообщений в день, появляется шутка внутри офиса, что компания должна использовать прием по электронной почте на рассылку как событие триггер для критически важных услуг: это как по маслу, что новые сообщения приходят в любое время дня и ночи. На основе Zope все время появляются новые системы, включая фреймворк управления контентом (на котором был и остается, по сей день, основан Plone).
Где-то в это время, разработчик из Филадельфии наблюдает, как работа начинается над следующей версии Zope, названной Zope 3. Zope 3 будет полностью несовместима со старыми Zope 2. Обещанно, что позже будет разработан некий слой совместимости, но Zope будет переработан и реинжинирится с нуля. Он исправит всё. К его разработке в Digital Creations относятся очень серьезно. Оригинальный основной автор Zope 2 посвящает себя ему более или менее полный рабочий день, и к нему на помощь приставлены некоторые разработчики компании из команды "A". Zope 3 будет основан на "компонентной архитектуре", которая позволит самостоятельно разработанным и проверенным компонентам, подключаться к нему, превращая Zope в то что нужно разработчику, давая ему возможность менять имеющиеся в наличии сторонние компоненты так, как необходимо, в отличие от относительной хрупкости и жесткости Zope 2. Он предпочитает композицию наследованию. Он даже имеет свой, основанный на XML, язык для этих компонентов, по имени ZCML. Вместо того, чтобы быть в значительной степени монолитной системой, как Zope 2, он будет состоять из очень мелких деталей, которые взаимодействуют. Разработчик из Филадельфии уверен, что это будет здорово, потому что очень умные люди, которых он уважает, работают над этим.
Разработчик из Филадельфии смотрит на то, как сотни тысяч строк кода Zope 3 написаны. Команда разработчиков учится писать хорошие тесты (хотя она никогда не научиться писать хорошую документцию). Самые лучшие инженеры Digital Creations сотворили нечто из Zope 3. Он медленно превращается в сложную систему, которая имеет внутреннюю красоту, но очень отличается от Zope 2, и гораздо сильнее отличается, от всего остального в мире веб-разработки. Предполагается что это займет год или два. Это заканчивается тем, что ушло четыре года, чтобы увидеть первую не-бета-версию. Zope 2 продолжает быть популярным в это время, но многие люди озабочены своим будущим, учитывая призрак Zope 3. К большому разочарованию разработчика из Филадельфии (который занят, по большей части, поддержкой проектов на Zope 2 в Digital Creations в это время), когда выходит первый релиз Zope 3, он так отличается, к нему так трудно подступиться в целом, и так плохо документирован, что многие люди невыдерживают, и начинают искать альтернативы Zope целиком, и люди с очень простыми требованиями быстро находят более подходящие альтернативы.
Между тем, Digital Creations меняет свое название на Zope Corporation, и медленно начинает урывками развивать гораздо более венчурно-капитало-ориентированную модели бизнеса. Она пытается создавать продукты для продажи ($ $ $ $ $ $ $ $ $ $), а не делать прямой консалтинг ($). Компания становится менее инженеро-ориентированная (и более продаже-ориентированная) в результате, и в конце концов земля уходит из-под ног для Zope 3 проекта, потому что компания просто не может оправдать продолжающиеся расходы на создание нового Zope, когда все ее доходы идут с проектов все еще использующих старые технологии Zope 2. Основатель обоих проектов, Zope 2 и Zope 3, вносит все меньше кода, так как их внимание потребляется созданием продуктов для продажи. Вклады в открытый код от третьих сторон в Zope 3 проекта нетривиальны, но без поддержки Zope Corporation, они кажется не могут изменить ситуацию.
Zope 3 никогда не получает массового признания. Некоторые из его технологий, такие как его компонентная архитектура, привиты обратно в Zope 2. Но это лишь приводит к тому, что и так очень сложный Zope2 становится еще более сложным. Такие проекты как Bluebream и Grok используют Zope3 как основу для построения фреймворков более выкого уровня, но они также не получают массового признания. Люди не уверены, чем "Zope" является в результате пяти лет муток с брендом. "Что такое Zope? Это Zope 2? Это Zope 3? Это Zope Corporation? Это пакет на PyPI? Это набор пакетов?" Все эти ответы верны. В результате бренд становится во многом бессмысленным, обозначая всё и ничего одновременно. Ужасающе, в то время как появляется другой хорошо документированный и хорошо спроектированный фреймворк Django, бренд быстро становится объектом презрения. Тройное проклятие: неудача основанная на синдроме второй системы, отсутствие постоянной поддержки со стороны своего крупнейшего участника и мутки с брендом, позволят использовать слово “Zope”, даже тем кто никогда не использовал ничего связанного с Zope, как синоним “перепроектирование” и “высокомерие разработчика” в более широком сообществе Python. Популярность Zope2, первоначального сервера приложений, в основном безупречного, за исключением того, что он остается монолитным и сложным, сильно страдает. Бренд потерял большую часть своей репутации и все что имеет “Zope” в своем названии начинает восприниматься с подозрением, и получает мало уважения, даже вещи очень мало связанные с веб-разработкой.
Однако, несмотря на бедствия бренда, разработчик из Филадельфии знает, что некоторые технические преимущества от реинжиниринга Zope довольно успешны. Объектная база данных Zope, ZODB, вычленена из Zope целиком и полезна сама по себе. "Компонентная архитектура" (фактически “суперсловарь” с претенциозным названием) оказывается полезной для выполнения очень быстрого поиска на основе сложных запросов. Система интерфейсов в Zope 3 позволяет структурированное утиное типирование объектов на основе экземпляра (а не класса), и оказывается, в некоторой степени, полезными для документации API. Первоначальный смысл в существовании Zope для разработчика из Филадельфии, его декларативная контекстно-зависимая система безопасности, полностью увязла при переезде, и не может быть повторно использована, но идея осталась. Концепция Zope об "обходе" по графу объектов, чтобы найти контекст безопасности оказывается чрезвычайно популярным в Zope 2 и Plone мире, и не имеет аналогов в конкурирующих системах того времени.
Так что, как вы наверняка догадались, конечно, я тот разработчик из Филадельфии. И я пережил все это. И я не могу сказать, что я полностью доволен тем, как все обернулось. Мне больно видеть, как все пинают Zope. Но несколько вещей стали мне ясны, во время этого пути:
- - Большинство разработчиков очень, очень не склонны к риску. Им нравятся делать маленькие шаги или не делать вообще. Вы должны позволить им использовать знакомые технологии и позволть им неиспользовать вещи, которые им мешают.
- - Привлекательность полностью интегрированной, монолитной системы, которая эффективно предотвращает использование альтернативных методов разработки и технологий в конечном итоге сойдёт на нет. И когда это произойдет, она прекратит свое существование с отмщением.
- - Естественная реакция на проблему монолитности системы, которая заключается в том, чтобы сделать абсолютно всё одинаково "подключаемым" также абсолютно проигрышно.
- - Тесты очень важны.
- - Документация является еще более важной, чем тесты.
- - При попытке заменить сложную систему, сделай её проще, а не размазыай сложность вокруг.
- - Бренды важны. Вы, в идеале, должны убедиться, что на вопрос "Что такое нечто" есть один ответ. Хитрость и брендинг не смешиваются, они производят токсичный дым путаницы.
Pyramid находится под сильным влиянием Zope; во многих областях, это бесстыдное производное. Без Zope, конечно, не было бы Pyramid. Но в то же время, Pyramid является реакцией на Zope. Мы создали Pyramid, потому что мы пришли к пониманию, что было неоптимальным в Zope и то, что было отличным, а не потому, что мы его не поняли. Делая это, мы использовали некоторые пакеты с "zope" в своем названии, мы сделали это, потому что они были вынесены из Zope достаточно хорошо, чтобы использовать повторно. На Pyramid также в значительной степени повлияли Pylons и Django, но по иронии судьбы, мы не смогли использовать что-нибудь от любой из этих систем очень легко, потому что они не были сделаны с таким расчетом.
- Pyramid использует пакет
- - Контекст поиска для декларативной контекстной подсистемы безопасности (ACL система авторизации).
- - Поиск “вьюхи” на основе контекста (например, “вьюха” на исключение).
zope.interface чтобы обеспечить:
Pyramid использует пакет zope.deprecation, чтобы предупредить пользователей фреймворка об устаревающих API методах. Он не имеет никаких зависимостей и составляет всего около 100 строк кода, которые на самом деле не имеет ничего общего с "Zope-сервер-приложений".
Пользователям не нужно знать или заботиться о них чтобы использовать Pyramid. Разработчики фреймворка использовали их, поскольку они являются ответом на актуальные требования. Мы могли бы форкнуть их и изменить их имена, и Zope-скептик просто не узнал бы. Мы могли бы даже переиздать их под другим именем, и они, вероятно, мгновенно стали очень популярны! Но форкать их только, чтобы изменить их имена чтобы успокоить тех, кто хочет двоичной простоты "Zope == плохой", также будет невероятным неуважением к сотням людей, которые очень много работали над ними. Те люди заслуживают уважения и восхищения, несмотря на трагедию Zope брендинга. Они внесли больше, чем я когда-либо внес (а может и внесу) в мир веб-Python, и, возможно, больше, чем вы тоже.
Таким образом, людям, которые хотят предварительно сделать очень плохие заключения "Zope == плохо, Pyramid == Zope, Pyramid == плохо", я предложил бы, чтобы вы были храбры. В ваших первых десять минут оценки, учитывая материал, который я написал выше, попробуйте на мгновение принять идею, что история с Zope зависимостями Пирамиды не написана полностью несчастными остолопами. Если вам нужны конкретные позитивные моменты, старайтесь думать о чем-то вроде этого: Mac OS X сегодня поставляется с zope.interface из коробки и подобное этому распространение затрагивает больше пользователей, чем ты и я вместе взятые плюс все наши друзья (и может быть, даже все их друзья). Считайте, что общее мнение которое вы получили от Reddit или того парня, который использовал Zope-сервер-приложений один день в 2002 году, может не иметь никакого значения. Пожалуйста, оставте временно своё недоверие, пока Вы не напишете своё первое нетривиальное приложение на Pyramid. После этого конкретная критика приветствуются.