Понимание внутренностей Zope, от глаз Django

Я отвечаю, не имея большого опыта в обоих случаях, но у меня была возможность манипулировать обоими, поэтому я могу высказать свое мнение по некоторым из ваших вопросов.

1) Какова «настоящая» цель zodb как таковой? То есть я знаю, что он делает, но скажи мне одну замечательную вещь, что zodb делает и фреймворк вроде django (который не имеет zodb) отсутствует

Распределение нагрузки через ZEO и поиск через ZCatalog. С этой точки зрения Django находится на очень низком уровне. Чтобы добиться того же, вам придется переоборудовать множество колес, треугольных. Вскоре я узнал следующее: не связывайтесь с проблемами баз данных низкого уровня. Вы их облажаете. Это банка с червями, размером с дюну .

Так почему же стоит выбрать ORM django? Вам также следует подумать, если YAGNI . django простой и самодостаточный, документация - премиум-класса, и когда (если) ваш сайт вырастет настолько сильно, вы переключитесь на лучший ORM (или на чистый OODB, в случае ZODB) позже.

2) Говорят, что один из убийц зопа особенность - TTW (через Интернет или Разработка с использованием ZMI) философии. Но Я (и любой разработчик) предпочитаю Разработка на основе файловой системы (с использованием Контроль версий с использованием Eclipse, с использованием любой любимый инструмент за пределами Zope). потом где на самом деле используется этот TTW?

Я не могу дать должного ответа на этот вопрос, но я бы не сказал, что развиваться с таким подходом принципиально плохо. Конечно, это изменение мышления, и я также предпочитаю разработку на основе файловой системы.

4) Действительно ли это хороший шаг для работы над Zope, от Django?

Zope 3 очень модульный, поэтому вы можете свободно использовать многие из его компонентов из django. Я бы не советовал этого делать. Можно, конечно, но больше всего я обнаружил отсутствие помощи. Немногие люди используют компоненты zope и django одновременно. Рано или поздно у вас возникнет проблема, и гугл не поможет. В этот момент вы поймете, что если ваша жизнь была видеоигрой, вы определенно играете в нее на сложном уровне (может быть, экстремальном, если вам придется сунуть нос в код zope).

Перво-наперво: текущие версии zope2 также включают в себя все zope3. И если вы посмотрите на современные приложения zope2, такие как Plone, вы увидите, что оно использует много «zope 3» (теперь называемого «zope tool kit», ZTK) под капотом.

Настоящая цель ZODB : это одна из немногих объектных баз данных (в отличие от реляционных баз данных SQL), которая действительно широко используется. Вы можете «просто» хранить там все свои объекты Python без необходимости использования объектно-реляционного сопоставителя. Никакого "select * from xyz" под капотом. И добавление нового атрибута к объекту zodb "просто" сохраняет это изменение. Роскошно! Особенно удобно, когда ваши данные не могут быть легко сопоставлены со строгой реляционной базой данных. Если вы можете легко отобразить : просто используйте такую ​​базу данных, я ' Я несколько раз использовал sqlalchemy в проектах zope.

TTW: мы вернулись к этому. По крайней мере, у zope2-способа TTW действительно есть все недостатки, которых вы боитесь. Никакого контроля версий, никаких внешних инструментов и т. Д. Plone экспериментирует (google для "ловкости") с красивыми явными zope 3 способами выполнения TTW-разработки, которые все еще могут быть отображены обратно в файловую систему.

TTW: zodb упрощает эту задачу. и дешево хранить всевозможные настройки конфигурации в базе данных, так что обычно вы можете настроить множество вещей через браузер. Впрочем, это на самом деле не считается типичной разработкой TTW.

Получение: удобный трюк, хотя он приводит к огромному загрязнению пространства имен. Обоюдоострый меч. Чтобы улучшить отладку и обслуживание, мы стараемся в большинстве случаев обойтись без него. Получение происходит внутри «графа объекта», так что подумайте " имеет множество функций для создания больших приложений (в том числе не веб). Посмотрите, например, на grok ( http://grok.zope.org ) дружественный упакованный zope. Чистую компонентную архитектуру также можно использовать в проектах django.

Очень хороший справочник по ZODB - это Руководство программиста ZODB / ZEO . ZODB - это не ORM. Это настоящая объектная база данных. Объекты Python прозрачно сохраняются в базе данных, не беспокоясь о том, как преобразовать их в представление, подходящее для базы данных. Внутри ZODB может быть сохранен любой поддающийся обработке объект Python. Реляционные базы данных подходят для больших объемов плоских данных (например, записей сотрудников), в то время как ZODB лучше всего подходит для иерархических данных (обычно присутствующих в веб-приложениях). Я лично использую Zope 3 для своих приложений. Я никогда не занимался типом работы TTW. Лучшая часть использования ZODB заключалась в том, что мне вообще не приходилось беспокоиться о том, как я буду сохранять данные и как все изменится, когда я обновлю свое программное обеспечение с одной версии до следующей. Например, если я добавляю новый атрибут к классу Python, все, что мне нужно сделать, это указать значение по умолчанию в качестве атрибута класса. Затем он становится автоматически доступным для всех объектов, созданных с помощью предыдущей версии того же класса. Удаление атрибута - это простая операция del для существующих объектов. Кстати, ZODB может использоваться независимо в любом приложении Python и не связан только с платформой ZOPE. Мне нравится тот факт, что мне не нужно беспокоиться о мельчайших деталях SQL при работе над приложениями Python, спасибо ZODB. И, конечно, если вам нужен сервер базы данных, чтобы вы могли запускать несколько копий вашего приложения на одном сервере, ZEO приходит вам на помощь поверх ZODB.

Zope исходил из идеи стать средой публикации объектов. С этой точки зрения сопоставление URL-адреса непосредственно с иерархией объектов в ZODB было отличным. URL-адреса просто отражают иерархию объектов. Что касается определения URL-адреса, всегда есть отладочный интерфейс Роттердама для помощи. Для разработки я оставляю флажки разработки в конфигурации zope и просматриваю содержимое ZODB через интерфейс Роттердама. Скин Роттердама предоставляет отличный способ самоанализа объектов Python, хранящихся в ZODB, и выяснение URL-адресов гораздо более интерактивно. Более того, для основных контейнеров в моем ZODB я регистрирую их как постоянные утилиты внутри менеджера сайта (сайты Zope 3 и менеджеры сайтов). В любом месте моего кода, когда мне нужен доступ к таким контейнерам, все, что я делаю, - это getUtility (IMyContainerType). Я не Мне даже нужно помнить подробное расположение этих контейнеров внутри кодовой базы. Когда-то они регистрируются менеджером сайта и в дальнейшем доступны в любом месте базы кода через вызовы getUtility (). И URL-адреса также поддерживают пространства имен. Например, используя пространство имен ++ skin ++, вы можете в любой момент изменить скин своего веб-приложения. Используя пространство имен ++ language ++, вы можете в любой момент изменить предпочтительный язык вашего пользовательского интерфейса. Используя пространство имен ++ attributes ++, вы можете получить доступ к отдельным атрибутам объекта. URL-адреса просто намного более мощные и более настраиваемые. И вы можете написать адаптеры обхода, определить свои собственные пространства имен, чтобы расширить возможности ваших URL-адресов. Чтобы привести пример, все страницы, к которым можно получить прямой доступ из веб-интерфейса, являются частью моего скина по умолчанию. В то время как все страницы, вызываемые с помощью фоновых вызовов AJAX, находятся под другой оболочкой. Таким образом, можно реализовать разные способы механизмов аутентификации в разных скинах. В основном скине, один перенаправляется на другую страницу входа в систему в случае сбоя аутентификации. Для страниц AJAX можно просто получить ошибку HTTP. Это можно сделать централизованно. Объекты Zope 3 имеют интерфейсы, и одно представление может быть определено для нескольких интерфейсов. Везде, где у вас есть объект, поддерживающий данный интерфейс, все связанные представления становятся автоматически доступными, и все такие URL-адреса автоматически становятся действительными. Если подумать, это гораздо более мощный инструмент, чем один файл python или файл XML, в котором URL-адреса жестко запрограммированы. Я мало что знаю о DJango и J2EE, поэтому не могу сказать, имеют ли они эквивалентные возможности.

Везде, где у вас есть объект, поддерживающий данный интерфейс, все связанные представления становятся автоматически доступными, и все такие URL-адреса автоматически становятся действительными. Если подумать, это гораздо более мощный инструмент, чем один файл python или файл XML, в котором URL-адреса жестко запрограммированы. Я мало что знаю о DJango и J2EE, поэтому не могу сказать, имеют ли они эквивалентные возможности.

Везде, где у вас есть объект, поддерживающий данный интерфейс, все связанные представления становятся автоматически доступными, и все такие URL-адреса автоматически становятся действительными. Если подумать, это гораздо более мощный инструмент, чем один файл python или файл XML, в котором URL-адреса жестко запрограммированы. Я мало что знаю о DJango и J2EE, поэтому не могу сказать, имеют ли они эквивалентные возможности.

ZODB - это база данных в стиле объектно-ориентированного программирования, которая не требует определения схемы. Вы можете просто создавать (почти) все виды объектов и сохранять их.

TTW иногда раздражает, но вы можете смонтировать ZOPE-object-tree с помощью webdav. Затем вы можете редактировать шаблоны и скрипты с помощью вашего любимого редактора.

ZOPE особенно эффективен для создания CMS-подобных систем, имхо там он по-прежнему не имеет себе равных - вам придется пройти через многое, чтобы заставить его работать одинаково хорошо в Django.

И через TTW, на самом деле, не разработчики, такие как дизайнеры, имеют хорошие шансы разработать, например, шаблоны и CSS, без необходимости взаимодействия с разработчиком.

On the ZODB:

Another way to ask "What is the real purpose of the ZODB?" is to ask, "Why was the ZODB originally created?"

The answer to that is the project was started very early on, around 1996. This was before the existance of MySQL or PostgreSQL, when miniSQL (a free-to-use but not free software) database was still in common use, or big money databases such as Oracle. Python provided the pickle module to serialize Python objects to disk - but serialization is lower level, it doesn't allow for features such as transactions, concurrent writes, and replication. This is what the ZODB provides.

It's still in use today in Zope because it works well. If you have no existing skillset in realational databases, it's easier to learn to use the ZODB than a relational database. It's also usable simpler use-cases, for example if you have a command-line script that needs to store some configuration information, using a relational database means having to run a database server just to store a little bit of configuraiton. You could use a config file, but the ZODB also works quite nicely because it's an embedable database. That means that the database is running in the same process as the rest of your Python code.

It's also worth noting that the API used to store objects inside containers is different between Zope 2 and Zope 3. In Zope 2, containers are stored as attributes:

 root.mycontainer.myattr

In Zope 3, they use the same interface as Python standard dictionary type:

  root['mycontainer']myattr

This is another reason why it can be easier to learn to use the ZODB than the Django ORM, since Django has it's own interface for it's ORM which is distinct from Python's existing interfaces.

Through-the-web (TTW):

Again, understanding the reason for TTW goes back when Zope was developed. While it seems silly to break with well known developer tools such Subversion or Mercurial, Zope was developed in the late 90s when the only free version control system was CVS. Zope 2 had it's own simple version control capabilites, and they were as good as CVS (which is to say, "they were limited and sucky."). UNIX workstations cost a lot more money back then, and had far fewer resources, so System Administrators were much more guarded and careful about how servers were managed. TTW allowed people who might not normally be able to upload code to the server with sysadmin intervation a way to do that.

With text editors, emacs and vi have had ftp-modes, and Zope 2 can listen on an FTP port. This would allow you to develop so that code was stored in the ZODB (editable TTW), but it was common to edit this code using a emacs or vi.

Today in Zope, TTW is more rarely used or promoted since it no longer makes sense to do this. Disk space is cheap, servers are (relatively) cheap, and there are lots of developer tools which expect to interact with the standard filesystem.

Acquisition:

It was a mistake. It was a very confusing feature that caused lots of unexpected things to happen. In theory there are some interesting ideas to acquisition, but in practice it's best tossed in the bin and has little practical use.

Moving from Django to Zope:

Work started on Zope 3 in 2001. This fixed a lot of the problems with Zope 2. It's a testament to the Zope community that Zope 2 is still actively and well maintained, but it's hardly state-of-the-art. Zope 2 is really only interesting to learn from a historical perspective.

Zope 3 ended up getting evolved in a few different directions, and so modern incarnations of Zope are best expressed in the form of Grok, BFG or Bobo.

Grok is closest to Zope 3, and as such is a pretty large framework - it can be rather overwhelming at times when delving through it's code base. However, just like Django, or any other full-stack framework you don't need to use every part of Grok, it can be quite easy to learn the basic and create web applications with it. It's convention-over-configuration is second to none, and it's class-based Views give it a much tighter, arguably cleaner code base than a Django web application. It's URL routing system is extremely flexible, but also arguably over-engineered.

BFG is a "pay for only what you eat" framework written by long time Zope developer Chris McDonough. As such, it's closer to Pylons in spirit, where only the parts deemed core or essential to a framework are included. It also plays very well with WSGI. It only uses a few core Zope packages.

Bobo is a "micro-framework". It's just a way to route URLs and serve up an app. It doesn't use any Zope packages, so isn't strictly in the Zope family of web frameworks. But it was written by Zope's creator, Jim Fulton, who originally called the publishing part of Zope, "Bobo". The original Bobo, written in the early 90's, mapped URLs to packages and modules, so if your source code was layed out as:

mypackage.mymodule.MyClass

You could have a URL such as:

/mypackage/mymodule/MyClass

Which was very inflexible, and was replaced with URL Traversel in Zope 2, which is fairly complex. Bobo uses Routes, so it's a middle ground between dead-simple URL resolution and complex URL resolution - about the same in complexity as Django's URL resolution machinery.

+1 к ответу Пшеницы выше: «Zope 2 действительно интересно изучать только с исторической точки зрения». Пару лет я занимался разработкой Zope для большого сайта, 50% zope 2, 50% zope 3. Даже тогда (это было 2 года назад) мы работали над переносом всего с zope 2. Если у вас уже есть много вложено в существующий проект Zope 2, нет причин его использовать; там просто не так много будущего. И если у вас есть большой существующий проект zope 2, я бы посоветовал взглянуть на продукт под названием Five (шутка: 2 + 3 = 5), который направлен на

позволяют интегрировать Zope 3 технологий в Zope 2. Среди другие, это позволяет использовать Zope 3 интерфейсы, конфигурация на основе ZCML, адаптеры, страницы браузера (в том числе скины, слои и ресурсы), автоматическое добавление и редактирование форм на основе схемы, события объекта, а также Каталоги сообщений i18n в стиле Zope 3.

Когда все сказано и сделано, Zope 3 сильно отличается от 2, и, IMHO, гораздо лучше (хотя и более сложный). TTW является необязательным и не рекомендуется для большинства случаев. Неявное приобретение ушло.

Похоже, здесь люди объяснили, почему вы можете захотеть использовать ZODB, поэтому я подумал, что упомянул бы еще кое-что о Zope 3 (или Zope 2 с Five), и это хорошо. Zope имеет очень мощную систему для соединения различных компонентов приложения, которая называется Zope Component Architecture (ZCA). Он позволяет вам писать более или менее автономные и многократно используемые компоненты, которые можно соединять вместе стандартным способом. Сейчас я в основном занимаюсь разработкой Django, и иногда мне не хватает ZCA. В Django, возможность писать повторно используемые компоненты ограничена и носит произвольный характер. Но, как говорит Рейноут, zope.component (как и большинство пакетов zope, включая ZODB) работает вне фреймворка zope и может использоваться в проекте Django.

Тем не менее, ZCA имеет свои недостатки, одним из которых является утомительный процесс регистрации ваших компонентов в файлах XML; мне всегда казалось, что это немного похоже на Java. Одна из причин, по которой мне действительно нравится Grok http://grok.zope.org/, заключается в том, что он находится поверх zope.component и выполняет большую часть этой грубой работы за вас.

Итог: Zope 2 в основном тупиковый. Если ваш работодатель согласен с этим, начните искать Zope 3 или хотя бы Five. Я думаю, вы обнаружите, что у Zope 3 крутая кривая обучения по сравнению с Django, поэтому было бы неплохо прийти к нему через Grok, который сглаживает большую часть Zope 3 ' s более грубые края. Но я думаю, что для действительно большого или сложного веб-приложения с большим количеством движущихся частей я бы выбрал Zope вместо Django (и я говорю это как человек, который действительно очень любит Django). Для небольших проектов Django, вероятно, будет быстрее. Однако количественно определить «большой» и «маленький» в этом контексте сложно, и, вероятно, потребуется еще несколько тысяч слов. Если вас действительно интересует Zope 3, то для начала определенно стоит начать с книги Филиппа фон Вайтерсхаузена.

и, вероятно, потребуется еще пара тысяч слов. Если вас действительно интересует Zope 3, то для начала определенно стоит начать с книги Филиппа фон Вайтерсхаузена.

и, вероятно, потребуется еще пара тысяч слов. Если вас действительно интересует Zope 3, то для начала определенно стоит начать с книги Филиппа фон Вайтерсхаузена.