Структура Zope3 сайта :

Введение :

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

Продукт "Сайт" :

Теоретически, сайт на основе Zope3 может не использовать никаких нестанадартных продуктов или настроек, и тогда никакого продукта создавать, конечно, не придется. Но на практике, любой поставщик интернет-услуг будет и предоставлять собственные продукты и настраивать уже существующие. Рассмотрим типовой случай размещения исходного кода такого сайта.

Собственные продукты :

Если сайт использует какие-то нестандарные продукты, то лучше всего оформить их по всем правилам Zope3-продуктов (см. например Скелет контент класса в Zope.txt), возможно, сделать из них пакеты eggs, зарегистрироовать на PyPI и установить стандартным образом.

Желательно выбрать для продукта лицензию ZPL или GPL, чтобы он мог стать общественным достоянием, и конечно, оставить возможность настройки его под частные нужды, о чем надо серьезно подумать ещё до начала разработки.

Таким образом, наличие собственных продуктов не порождает никаких особенностей по настройке сайта Zope3.

Настройки :

Пусть у вас есть некоторое число установленных и доступных для использования, но разрозненных продуктов (папкии, изображения, файлы, новости, чаты, форумы и любые другие), которые вы намерены использовать на своём сайте как части некой единой системы, но не очень представляете себе как. В большинстве случаев всё довольно просто и подобные проблемы решаются стандартным образом с помощью различных настроек.

Словом "Настройки" обозначают совокупность параметров, цель которых - объеденить разрозненные "смыслы" различных продуктов (выраженные через их интерфейсы) единой идеей, которая опять-таки выражается через интерфейсы и управляется ими.

Настройки - это широкое понятие, включающее в себя множество деклараций, сделанных через ZCML, но не ограниченное только ими. Дадим краткий список и классификацию:

Управление вхождением в контейнеры

Это повсеместая задача, которую необходимо будет решить на любом из сайтов. Например, вы хотите чтобы файлы добавлялись только в контейнеры с одним интерфейсом, изображения только в контейнеры с другим конкретным интерфейсом и т.п. Существует несколько методик писать продукты так, чтобы управление вхождением в контейнеры можно было осуществлять без перепрограммирования самих продуктов. Обычно это осуществляется назначением директивой class интерфейсов либо контейнерам, либо их содержимому. Вариант такой методики был использован в notestrict, описанном в статье Скелет контент класса в Zope.txt;

Назначение дополнительных интерфейсов контент-классам

Как правило, чужим контент-классам можно без проблем назначить дополнительные интерфейсы. Эти интерфейсы могут носить характер схем с дополнительными атрибутами (стандартные формы добавления и редактирования легко могут обслужить такой вариант), интерфейсы, включающие дополнительные аннотации у контент-класса или интерфейсы, включающие дополнительные виды для контент-класса (см. например, продукт ks.interfaceswitcher или ng.schema.interfaceswitcher);

Создание адаптеров разнородных объектов к единым интерфейсам

Также повсеместная задача. Подобные адаптеры любят использовать, например, при индексации объектов (для индексации по таким полям, которых выбранные вами объекты сайта могут не предоставлять непосредственно) или построении для них универсальных видов. Создание адаптера, казалось бы, неминуемо влечет за собой написание собственного кода, но на самом деле, благодаря таким продуктам как ng.zcmljunction создание адаптера может сводится к декларациям в ZCML.

Обертывание не-Zope3 продуктов для использования в Zope

Уже неоднократно отмечалась возможность такого действия. В самом деле, достаточно объявить класс из не-Zope3 продукта директивой class, назначить ему интерфейсы, права, формы создания, просмотра и редактирования и все готово. С практической точки зрения это все-таки больше похоже на создание нового Zope3-продукта, чем на настройку сайта, но всё же упомянем это как возможное действие.

Использует сайт собственные продукты или только чужие - не имеет большого значения: все равно все продукты должны быть настроены для совместного использования. Для хранения такой настройки можно порекомендовать создать специальный продукт, с условным названием "Сайт" (NeuralSite, DreamBotSite, MySite, TheSite) и все настройки разместить в нём.

Инсталлятор :

Если предполагается создать тиражируемый сайт, то желательно написать специальную фабрику, создающую структуру этого сайта в ZODB, и назвать ее инсталлятором. Такой инсталлятор можно сделать на основе интересного продукта ks.installtool.

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

Скины :

Создание собственного сайта подразумевает создание собственного скина. Скин лучше всего оформить как отдельный продукт с условным названием "Скин" (NeuralSkin, DreamBotSkin, MySkin, TheSkin). Если предполагается создать тиражируемый сайт, то, возможно, для каждого экземпляра этого сайта придется создавать новый скин. Это не слишком сложно, если наследовать каждый новый скин от общего прототипа и менять в нем только несколько существенных деталей. Тем не менее, будет лучше, если установленный сайт будет позволять настраивать скин.

Структура данных в Zope/ZODB :

Выше речь шла о расположении исходного кода будущего сайта, теперь расмотрим типовую структуру расположения компонентов в ZODB.

Во временя Zope2 была традиция вводить двухступенчатую структуру сайта в Zope/ZODB: первая папка называлась "Подвал" и содержала специализированные темлейты страниц, SQL-методы и прочий "исполняемый" контент вместе с настройками, в нее вкладывалась папка "Main", которая называлась "Корень сайта". В последствии, именно на папку "Main" настраивался прокси, чтобы отображать ее в корне сайта, а "Подвал" оказывался недоступен.

В Zope3 введено специальное пространство имен, через специальный url которого (++etc++site) можно получить доступ к так называемому "Сайт-Менеджеру" (LocalSiteManager), если он был создан для данного контейнера. Такая возможность полностью меняет рекомендации к структуре сайта: подвал сайта (место, где хранятся инструменты для работы с сайтом) расположен теперь в cайт-менеджере, а корнем является непосредственно контейнер, снабженный сайт-менеджером. Внутри сайт-менеджера можно создавать различные объекты, в том числе "папки сайт-менеджера", что позволяет хорошо структурировать его содержимое.

Сайт-менеджер предоставляет интерфейс IComponents, т.е. предоставляет локальные экземпляры реестров компонент. API работы с реестрами построено таким образом, что любое обращение к реестрам просматривает реестры от локальных к глобальным: т.е. в порядке обратном вложению контейнеров, снабженных сайт менеджерами. Подробнее об этом можно прочитать в Архитектура реестров.txt, а некоторые тонкости реализации можно узнать в SiteManager.txt.

Вышеизложенное явно напоминает об одном из основных принципов взаимодействия в Zope: все сервисы должны быть зарегистрированы как утилиты в реестре утилит. В приложении к структуре данных сайта этот принцип немного усложняется: все утилиты создаются в сайт-менеджере или его папках и регистрируются в его реестрах.

Существует несколько часто используемых утилит.

Утилита уникальных идентификаторов (IIntIds) :

Позволяет по любому заданному объекту получить уникальный идентификатор. Этот уникальный идентификатор не изменяетя в течении всего времени жизни объекта и на самом деле в настоящее время основана на _p_oid, хотя и получается через кучу адаптеров. В принципе, в случае необходимости есть возможность изменить способ генерации идентификатора, но пока ей никто не воспользовался.

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

Поисковый каталог (ICatalog) :

Осуществяляет индексацию объектов сайта. Индексация требует создания внутри каталога индексов, которым передается событие изменения объекта и сам объект. Удобно, чтобы при индексации объекты адаптировались к специальному интерфейсу индексации. Это позволяет сократить количество индексов и упорядочить синтаксис запроса к поисковому каталогу.

Поисковый каталог испрользует утилиту уникальных идентификаторов и должен создаваться после нее. В то же время, поисковый каталог позволяет переиндексировать содержимое в любое время.

Заключение :

Итак, мы рассмотрели типичный набор продуктов, из которых будет состоять практически любой сайт (это собственно, используемые продукты, продукт для ограничения вхождением в контейнеры, назначения дополнительных интерфейсов, и регистрации необходимых адаптеров, инсталлятор и скин) и рассмотрели то, как рекомендуется располагать компоненты в ZODB (инструменты и утилиты - в сайт-менеджере, всё остальное просто в контейнере сайт-менеджера).

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