Версия 22 от 2010-06-09 13:12:47

Убрать это сообщение

Конценпции и технологии

Концепции

Интерфейсы (Interface)

Интерфейсы - это объекты, описывающие внешнее поведение других объектов, которые предоставляют (provide) реализуемые ими интерфейсы (своего рода спецификация). Интерфейс предоставляет спецификацию объектов, которые их реализуют через:

Вот несколько преимуществ, которые вы получаете при использовании интерфейсов:

Компонентная архитектура Zope

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

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

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

События (Event)

События - это объекты, которые сигналят о том, что в системе что-то случилось. Они используются для расширения обработки запросов путем обеспечения точек вставки реакции на них (plug points). Пакет zope.event обеспечивает базовую систему публикации событий. Также этот пакет предоставляет очень простую диспетчерскую систему, на основе которой можно построить более сложные. Например, в пакете zope.component находится диспетчерская система основанная на типах, и построена она на основе пакета zope.event.

Адаптеры (Adapter)

Адаптеры используют интерфейс существующего компонента и адаптируют этот компонент, наделяя возможностью предоставлять другой интерфейс.

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

Адаптеры предоставляют возможность избежать этого, реализуя принцип подстановки Лисков.

Адаптеры предоставляют механизм сотрудничества между данным объектом и конкретным контекстом посредством интерфейсов. Они позволяют произвольному классу быть совместимым с данным интерфейсом, предоставляя слой совместимости (compatibility layer).

Этот механизм используется и в других системах, например, Microsoft COM QueryAdapter, и позволяет разработчику собирать объекты в специфический функционирующий контекст. Другое название этого механизма - склеивающий кода (glue code).

Использование адаптеров предоставляет следующие преимущества:

Утилиты (Utility)

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

Утилиты в большинстве случаев используются для создания простых компонентов, которые выполняют одно простое задание, например, синтаксический анализатор XML. Иногда очень полезно зарегистрировать объект, который ничего не адаптирует. Примерами таких объектов могут служить: соединение к базе данных, синтаксический анализатор XML, объект, генерирующий уникальные идентификаторы и т.д. Этот тип компонентов предоставляется ZCA и называется вспомогательными компонентами (utility components).

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

Подписчики (Subscriber)

В отличии от обычных адаптеров, адаптеры-подписчики (subscription adapters, subscribers) используются тогда, когда нужны сразу все адаптеры, которые адаптируют объект к определенному интерфейсу. Адаптеры-подписчики также известны как просто подписчики.

Обработчики (Handler)

Обработчики - это фабрики подписчиков, которые ничего не производят. Они просто выполняют свою работу в тот момент, когда их вызвали. Обработчики обычно используются для оказания реакции на события. Обработчики также называют подписчиками на события (event subscribers) или адаптерами-подписчиками на события (event subscription adapters).

Подписчики на события (Event subscribers) отличаются от других подписчиков тем, что тот, кто их вызывает не ожидает от них прямого взаимодействия. Например, от публикатора событий (event publisher) не ожидается никакого возвращаемого значения. Рекомендуется оформлять подписчики в виде функций, а не классов, из-за того, что подписчики не предоставляют программного интерфейса (API) тем, кто их вызывает.

Реестры компонентов

Реестры хранят список доступных компонентов, информацию о том, какие интерфейсы они предоставляют, какой интерфейс(ы) они, возможно, адаптируют, а также необязательное регистрационное имя. Пакет zope.component реализует глобальный реестр компонентов. Пакет zope.site предоставляет локальный персистентный реестр компонентов, который называется сайт-менеджер (site manager), и предназначен для регистрации локальных утилит и адаптеров.

Публикация объектов

BlueBream выкладывает объекты в веб. Этот процесс называется публикацией объектов. Одна из уникальных характеристик BlueBream - это способ, который предлагается для перехода от объекта к объекту, и вызова методов этих объектов только с помощью URL. Вдобавок к HTTP, BlueBream предоставляет возможность публикации путем использования и других протоколов как FTP, WebDAV и XML-RPC.

Виды (view)

Виды обеспевивают связь между внешним воздействием и объектом.

Вид обычно является компонентом отображения, и в большинстве случаев является ответственным за создание HTML-кода. Виды могут возвращать HTML напрямую, но часто также содержат логику отображения и обрабатывают данные для передачи в шаблон страницы (Zope Page Template), который уже содержит HTML.

Веб-разработчики обычно имеют дело со специальным типом видов, который именуется видом обозревателя (BrowserView). Это обычный вид (View), созданный для веб-браузера, но BlueBream также предоставляет виды для других протоколов, таких как FTP или WebDAV. В виде обозревателя, внешним воздействием является запрос (request), а объект, к которому будет применен вид ищется путем траверсинга (traversal) и называется контекстом. Большинство Zope разработчиков, говоря вид имеют в виду именно вид обозревателя, поскольку веб - наиболее часто применяемая среда для публикации объектов.

Констурктор браузерного вида (BrowserView) выглядит следующим образом:

   1 class BrowserView(Location):
   2     implements(IBrowserView)
   3 
   4     def __init__(self, context, request):
   5         self.context = context
   6         self.request = request

Контекст - это объект, на который воздействует вид. Часто контекст является контент-объектом, и это может быть даже объект-контейнер (Container),объект-сайт (Site), или любой другой объект, который Zope может опубликовать.

Запрос (Request) - это HTTP запрос. Если вид является видом обозревателя, запрос будет содержать аттрибут form, который хранит все данные форм, которые доступны программисту в подготовленном виде.

Представим себе следующий адрес: http://localhost:8080/your-id/a-todo-list/get-cat-food. В BlueBream, your-id - это контейнерный компонент, который также предоставляет интерфейс !IHomeFolder, a-todo-list - контейнер задач, который также предоставляет интерфейс (!IToDoList), а get-cat-food - это компонент, что предстваляет единицу содержимого, а также предоставляет интерфейс (!IToDoItem). Если ввести URL http://localhost:8080/your-id/a-todo-list/get-cat-food в браузере, то контекстом будет объект, предоставляющий интерфейс !IToDoItem, в то время как запросом будет объект, который отображает HTTP-запрос. Но, если URL такой: http://localhost:8080/your-id/, то контекстом является ваша домашняя папка.

Вы можете сделать просмотр вида программным путем с помощью запроса (query):

   1 view = component.queryMultiAdapter((object, request), name='index')

Для получения более подробной информации о видах, обратитесь к разделу о них в Plone Core Developer Reference. Этот справочный материал предоставляет информацию о том, как виды BlueBream используются в Plone: http://plone.org/documentation/manual/plone-developer-reference/patterns/views.

Контент-объекты (Content object)

Контент-объекты, или объекты содержимого - это объекты, которые имеют виды, видимые пользователем.

Если интерфейс предоставляет тип интерфейса zope.app.content.interfaces.IContentType, то все объекты, которые предоставляют этот интерфейс считаются контент-объектами.

Контейнеры

Контейнеры - это контент-объекты, которые являются вместилищем для других контент-объектов.

Схемы (Schema)

Cхемы - это расширение интерфейсов, поэтому зависят от пакета zope.interface. Поля в схемах эквивалентны методам в интерфейсах. Вместе они дополняют друг друга, так как описывают разные стороны объекта. Методы интерфейса описывают функции, которые будет выполнять компонент, тогда как поля схемы отражают состояние.

Схемы обеспечивают:

Виджеты (Widget)

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

Виджеты делятся на две группы: виджеты отображения и ввода. Виджеты отображения (Display widgets) зачастую являются довольно простыми и показывают только текстовое представления объекта Python. Напротив, виджеты ввода (input widgets), являются более сложными.

Cлои (Layer)

Скины (Skin)

Define the “look” of a site Common artifacts: templates and resources (CSS, Javascript, etc.) Use layers to retrieve the data for templates Developed by HTML and Graphic Designer/Scripter Technically, skins are interfaces inherited from a special interface called IDefaultBrowserLayer. The IDefaultBrowserLayer is defined in zope.publisher.interfaces.browser module. You can also inherit from an already existing skin. It is also important to register the skin interface type as IBrowserSkinType. Skins are directly provided by a request.

Layers versus skins

Both are implemented as interfaces BlueBream does not differentiate between the two In fact, the distinction of layers defining the “feel” and skins the “look” is a convention. You may not want to follow the convention, if it is too abstract for you, but if you are developing application with multiple look and feel, I strongly suggest using this convention, since it cleanly separates concerns. Both support inheritance/acquisition