Текущий рабочий каталог (его можно узнать с помощью функции os.getcwd()) также не находится в одном каталоге с обработчиком.

#! — строка в первой строке сценария не определяет версию интерпретатора Python. Работает версия, для которой был скомпилирован mod_python.

Все необходимые параметры передаются в обработчик в виде Request–объекта. Возвращаемые значения также передаются через этот объект.

Web–сервер замечает, что сценарий–обработчик изменился, но не заметит изменений в импортируемых в него модулях. Команда touch mprocess.py обновит дату изменения файла сценария.

Отображение os.environ в обработчике может быть обрезанным. Кроме того, вызываемые из сценария–обработчика другие программы его не наследуют, как это происходит при работе с CGI–сценариями. Переменные можно получить другим путем: req.add_common_vars(); params = req.subprocess_env.

Так как сценарий–обработчик не является «одноразовым», как CGI–сценарий, из–за ошибок программирования (как самого сценария, так и других компонентов) могут возникать утечки памяти (программа не освобождает ставшую ненужной память). Следует установить значение параметра MaxRequestsPerChild (максимальное число запросов, обрабатываемое одним процессом–потомком) больше нуля.

Другой возможный обработчик — сценарий идентификации:

Листинг

def authenhandler(req):

password = req.get_basic_auth_pw()

user = req.connection.user

if user == «user1» and password == «secret»:

return apache.OK

else:

return apache.HTTP_UNAUTHORIZED

Эту функцию следует добавить в модуль mprocess.py, который был рассмотрен ранее. Кроме того, нужно дополнить конфигурацию, назначив обработчик для запросов идентификации (PythonAuthenHandler), а также обычные для Apache директивы AuthType, AuthName, require, определяющие способ авторизации:

Листинг

<Directory "/var/www/html/mywebdir»>

AddHandler python–program .py

PythonHandler mprocess

PythonAuthenHandler mprocess

AuthType Basic

AuthName «My page»

require valid–user

</Directory>

Разумеется, это — всего лишь пример. В реальности идентификация может быть устроена намного сложнее.

Другие возможные обработчики (по документации к mod_python можно уточнить, в какие моменты обработки запроса они вызываются):

Листинг

PythonPostReadRequestHandler

Обработка полученного запроса сразу после его получения.

Листинг

PythonTransHandler

Позволяет изменить URI запроса (в том числе имя виртуального сервера).

Листинг

PythonHeaderParserHandler

Обработка полей запроса.

Листинг

PythonAccessHandler

Обработка ограничений доступа (например, по IP–адресу).

Листинг

PythonAuthenHandler

Идентификация пользователя.

Листинг

PythonTypeHandler

Определение и/или настройка типа документа, языка и т.д.

Листинг

PythonFixupHandler

Изменение полей непосредственно перед вызовом обработчиков содержимого.

Листинг

PythonHandler

Основной обработчик запроса.

Листинг

PythonInitHandler

PythonPostReadRequestHandler или PythonHeaderParserHandler в зависимости от нахождения в конфигурации web–сервера.

Листинг

PythonLogHandler

Управление записью в логи.

Листинг

PythonCleanupHandler

Обработчик, вызываемый непосредственно перед уничтожением Request–объекта.

Некоторые из этих обработчиков работают только глобально, так как при вызове даже каталог их приложения может быть неизвестен (таков, например, PythonPostReadRequestHandler).

С помощью mod_python можно строить web–сайты с динамическим содержимым и контролировать некоторые аспекты работы web–сервера Apache через Python–сценарии.

Среды разработки

Для создания Web–приложений применяются и более сложные средства, чем web–сервер с расположенными на нем статическими документами и CGI–сценариями. В зависимости от назначения такие программные системы называются серверами web–приложений, системами управления содержимым (CMS, Content Management System), системы web–публикации и средствами для создания WWW–порталов. Причем CMS–система может быть выполнена как web–приложение, а средства для создания порталов могут базироваться на системах web–публикации, для которых CMS–система является подсистемой. Поэтому, выбирая систему для конкретных нужд, стоит уточнить, какие функции она должна выполнять.

Язык Python, хотя и уступает PHP по количеству созданных на нем web–систем, имеет несколько достаточно популярных приложений. Самым ярким примером средства для создания сервера web–приложений является Zope (произносится «зоп») (см. http://zope.org) (Z Object Publishing Environment, среда публикации объектов). Zope имеет встроенный web–сервер, но может работать и с другими Web–серверами, например, Apache. На основе Zope можно строить web–порталы, например, с помощью Plone/Zope, но можно разрабатывать и собственные web–приложения. При этом Zope позволяет разделить Форму, Содержание и Логику до такой степени, что Содержанием могут заниматься одни люди (менеджеры по содержимому), Формой — другие (web–дизайнеры), а Логикой — третьи (программисты). В случае с Zope Логику можно задать с помощью языка Python (или, как вариант, Perl), Форма может быть создана в графических или специализированных web–редакторах, а работа с содержимым организована через Web–формы самого Zope.

Zope и его объектная модель

В рамках этой лекции невозможно детально рассмотреть такой инструмент как Zope, поэтому стоит лишь заметить, что он достаточно интересен не только в качестве среды разработки web–приложений, но и с точки зрения подходов. Например, уникальная объектно–ориентированная модель Zope позволяет довольно гибко описывать требуемое приложение.

Zope включает в себя следующие возможности:

Web–сервер. Zope может работать с Web–серверами через CGI или использовать свой встроенный Web–сервер (ZServer).

Среда разработчика выполнена как Web–приложение. Zope позволяет создавать Web–приложения через Web–интерфейс.

Поддержка сценариев. Zope поддерживает несколько языков сценариев: Python, Perl и собственный DTML (Document Template Markup Language, язык разметки шаблона документа).

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

Интеграция с реляционными базами данных. Zope может хранить свои объекты и другие данные в реляционных СУБД: Oracle, PostgreSQL, MySQL, Sybase и т.п.

В ряду других подобных систем Zope на первый взгляд кажется странным и неприступным, однако тем, кто с ним «на ты», он открывает большие возможности.

Разработчики Zope исходили из лежащей в основе WWW объектной модели, в которой загрузку документа по URI можно сравнить с отправкой сообщения объекту. Объекты Zope разложены по папкам (folders), к которым привязаны политики доступа для пользователей, имеющих определенные роли. В качестве объектов могут выступать документы, изображения, мультимедиа–файлы, адаптеры к базам данных и т.п.

Документы Zope можно писать на языке DTML — дополнении HTML с синтаксисом для включения значений подобно SSI (Server–Side Include). Например, для вставки переменной с названием документа можно использовать

Листинг

<! — #var document_title ->

Следует заметить, что объекты Zope могут иметь свои атрибуты, а также методы, в частности, написанные на языке Python. Переменные же могут появляться как из заданных пользователем значений, так и из других источников данных (например, из базы данных посредством выполнения выборки функцией SELECT).

Сейчас для описания документа Zope все чаще применяется ZPT (Zope Page Templates, шаблоны страниц Zope), которые в свою очередь используют TAL (Template Attribute Language, язык шаблонных атрибутов). Он позволяет заменять, повторять или пропускать элементы документа описываемого шаблоном документа. «Операторами» языка TAL являются XML–атрибуты из пространства имен TAL. Пространство имен сегодня описывается следующим идентификатором: