Zope & Django
В своем разговоре об ошибках, присутствующих в сервере приложений Zope, я пытался призвать мир не повторять их. Затем я узнал на конференции PyCon 2008, что Django повторил некоторые из них. Mark Ramm также выступил на этой конференции с докладом о том, что может почерпнуть Django от Zope. Я не знаю, был ли он преднамеренным, но я почувствовал в речи Jacob Kaplan-Moss о проектных решениях Django, что последний пытается немного себя защитить.
Без сомнения, Django является хорошим web-фреймворком. Если бы это было не так, то он не был бы настолько популярен. И хотя я думаю, что он нуждается в некоторых изменениях, по большому счету они не столь важны. Единственное, что я понял для себя, это то, когда необходимо выбрать программное обеспечение, выбирайте то, что для вас актуально. Но своими комментариями я не хочу отпугнуть вас от Django, и навязать вам Zope technologies, выкрикнув “Эй, посмотрите на это, разве это не круто!? ” или возможно даже так “Иди туда, Сделай то, Это плохая идея”.
Архитектура и Моральные принципы
Я согласен с основными решениями Django. Они выбрали Python, с открытым исходным кодом, который конечно имеет продуманные настройки по умолчанию, что в большинстве случаев не требует дополнительной настройки конфигурации, а также, чтобы у Вас не было “architecture astronauts”. Есть такой тип программистов, которые любят создавать сложности ради собственного удовольствия, и если Вы позволяете им писать фреймворк, это будет удивительно, получится так сказать удивительный комплекс на грани непригодности. Но риск игнорирования “architecture astronauts - архитектурных астронавтов” - не является тем риском, о котором говорит Kaplan-Moss, утверждая, что Вы рискуете повторно изобрести велосипед. Риск того, что Вы загоняете себя в угол. Это не является проблемой программного обеспечения конечного пользователя, потому что Вы можете всегда улучшить его. Но это - проблема для фреймворков, потому что здесь ими пользуются другие люди, и когда Вы изменяете их, то Вы нарушаете работу чьего-нибудь программного обеспечения. Именно поэтому из такого затруднительного положения, когда вы создаете фреймворки, очень трудно выйти. Когда Вы проходитесь кистью по невысохшей краске, то портится не только ваша работа, но и работа того кто красил до вас. И вот для чего существуют гуру построения систем. Придумывая разные технологии создания они делают так, что Вы в конечном итоге не оказываетесь в безвыходном положении. Ах, да, Вы еще должны знать о парнях, которые хотят добавить гибкости систем, не удосужившись объяснить, как пользоваться этой самой гибкостью. Поступая таким образом, Вы создадите себе дополнительные сложности, потому что эта гибкость будет в тех местах, где она вам не нужна. Брокер объектных запросов Zope 3 предоставляет вам возможность выбрать способ траверса объекта (т.е. как Вы находите объект, к которому происходит обращение). Траверс по умолчанию предоставляет возможность изменять способ нахождения определенного объекта. И траверс объектов по умолчанию будет использовать __ getitem __, чтобы найти подчиненные объекты. Что конечно можно изменить. Существует три места, где Вы можете изменить подчиненные объекты вашего объекта. В этом просто нет необходимости. Но я должен еще найти хотя бы один случай, где самого простого __ getitem __ не достаточно.
Одна общая ошибка между Zope 2 и Django, состоит в том, что некоторые функциональные возможности, а именно безопасность объекта, реализуются с помощью специальных методов или атрибутов контентного объекта. Это хорошо на начальном этапе работы, но когда Вы хотите изменить способ работы системы безопасности, чтобы она была более гибкой, Вы должны добавить дополнительные атрибуты, но при этом сохранить обратную совместимость, чтобы сохранить работоспособность чужого кода. Но Вам придется иметь дело с множеством имен атрибутов, которые приводят к изменению поведения объектов непредсказуемым образом. Zope 2 сделал это, и не только с системой безопасности. В прошлом году я заметил, что Django тоже это сделал.
Полно-стековый или slim waist
Я не могу также критиковать их за то, что они являются полно-стековыми фреймворками. Я не соглашусь с Kaplan-Moss в том, что существует деление между полно-стековым фреймворком и “лучшим” фреймворком. И даже если Вы, как любой хороший разработчик, попытаетесь сделать ваш полно-стековый фреймворк из раздельных частей, которые могут использоваться независимо от всего фреймворка, если, конечно же, Вы не уверены, что он используется независимо от него, то начнут появляться зависимости. Zope 2 и Zope 3 также являются полно-стековыми фреймворками, по той же причине, что и Django: другого больше ничего не было. Очевидно, когда появился Django, существовали лишь Zope 2 и Twisted. Но единственная часть, которая была действительно независима от Zope 2, это ZODB, и Django решил создать ORM, а Twisted отказался использовать пулы потоков, которые снижают скорость его работы, поскольку они запускают потоки для каждого Web-запроса.
Мой путь или путь плагина
Я должен выразить протест по поводу критики Jacob Kaplan-Moss подключаемых компонентов. Во-первых, он говорит, что невозможно написать приложение с помощью STORM и затем щелкнуть переключатель и использовать вместо этого SQLAlchemy. Конечно так нельзя делать, если только Вы сейчас не пишите для них обертку, но на это уйдет больший объем работы, чем она того заслуживает. Дело в том, что Вы не должны увязать в этом. В Zope 2 Вы можете на практике использовать две системы шаблонов. Первая из них называется DTML, и вторая ZPT, которая намного лучше первой, но разработана несколькими годами позже. Но что делать, если они вам не нравятся? Что, если Вы хотите использовать что-нибудь другое. Вам может нравиться Zope 2 в целом, но Вам могут не нравиться обе эти системы: DTML и ZPT. Хорошо, в Grok, мы решили эту проблему очень легко, подключив другие системы шаблонов. Конечно, Вы не сможете переключаться между системами, в этом случаи вы должны будете переписать все ваши ZPT шаблоны. Но для следующего проекта, Вы можете использовать Genshi или что-то другое, что Вы захотите. (Фактически Вы можете использовать их все одновременно, но это можно сделать не со всеми типами подключаемых компонентов). Это предоставит Вам большую гибкость.
И здесь Jacob Kaplan-Moss заявляет, что наличие выбора это плохо. Его главный аргумент - это то, что Вы практически силой заставляете нового пользователя делать выбор, который он не в состоянии сделать, а это совершенно неправильно, потому что Django имеет продуманные настройки по умолчанию. В Grok та же история, когда Вы создаете проект Grok, то по умолчанию Вам будет предложен ZPT. Если Вы хотите вместо этого использовать Genshi, пожалуйста, вы можете это сделать, а гибкость позволит пользователю избежать дополнительных сложностей, если он не хочет переключаться. И Вам никого не придется заставлять силой делать выбор.
Jacob также утверждает, что Django может установить свой собственный темп контроля поведения на любом уровне стека. Это отчасти верно, но когда Вы создаете лучший фреймворк, у Вас основная масса людей вовлечены в качестве разработчиков компонентов, и Вы как главный разработчик этих компонентов можете, как правило, сами влиять на направления разработки и задавать любое количество релизов, когда они Вам нужны. И если Вы не являетесь таковым разработчиком, то Вы не сможете найти достаточное количество разработчиков, чтобы выполнить всю работу.
Действительно ли Django является новым Zope 2?
Jacob Kaplan-Moss признает риск того, что Django станет Zope. Но я так не думаю, хотя они уже прошли большой путь для этого. Надеюсь, они остановились. Я не знаю, надо ли им возвращаться, но, по крайней мере, им не следует идти дальше по пути Zope, если они хотят остаться актуальными. Поскольку, если Вы зашли так далеко, Вам придется проделать большую работу, чтобы вернуться и снова сделать систему востребованной.
По материалам regebro.wordpress.com
Автор: Lennart Regebro
Перевод ООО «Комтет» komtet.ru