Zope (www.zope.org) - это программный комплекс, предназначенный для создания сложных Web-приложений.
Рассмотрим пример... (позднее примечание - пример безнадёжно устарел,
и сервер, на котором он был размещён - тоже; сервер выключен, ссылка
на пример удалена. Приношу свои извинения. Bit rot...)
На этой странице ссылки на две тестовых программы. Первая программа
высвечивает таблицу. Простую HTML-таблицу, содержимое которой берется из
базы данных (в данном примере - из SQL-сервера Postgres). Ничего
особенного, и ничего сложного - любой программист, который начинает
осваивать связку "CGI + SQL" пишет такую программу.
Вторая тестовая программа. Те же самые данные, та же самая табличка,
только разбитая на блоки (batches) по 10 строк. Это уже несколько более
сложная задача. Сложность ее имеет (в традиционной связке "CGI + SQL")
двоякую природу. Первая проблема - при вызове CGI извлечь из SQL-сервера
ровно столько данных, сколько надо. Вторая - разработать технологию,
позволяющую в CGI иметь кнопки "Предыдущий/Следующий". Каждая из этих задач
тем или иным способом разрешима. Но, к сожалению, каждый раз программист ее
решает.
В данном случае Zope предлагает решение, близкое к идеалу.
Автоматическая разбивка на блоки и создание ссылок Prev/Next встроена в
Zope. так что мне осталось только сказать (при создании моей программы) -
возьми данные запросом SELECT * FROM table и выведи их блоками по 10 строк.
Все!
В парадигме CGI избежать взаимозависимости между дизайнером и программистом невозможно. Стоит дизайнеру захотеть изменить внешний вид сайта - и во многих CGI приходится вносить изменения. И наоборот - на правильно спроектированном сайте программист совершенно не пересекается с дизайнером. Главным достоинством Zope является полное разделение труда между программистом, дизайнером и content-менеджером. Приведенный в документации пример (http://www.zope.org/Documentation/Guides/ZCMG-HTML/ZCMG.2.1.1.html), показывает последовательность экранов, на которых работает Web-master, не прибегая к программированию. Zope решает это с помощью понятия "шаблонов". Шаблон рисуют дизайнер и content-менеджер, а программист добавляет блоки, наполняющие шаблон реальной информацией. Превращение полученного наполненного данными шаблона в HTML - тоже задача Zope.
Другим важным аспектом Zope является "наследование" (но не то, которое
inhritance, а то, которое aquisition). Например, когда шаблон спрашивает у
Zope - а какой у нас сегодня стандартный HTML footer, Zope пробежится по
иерархии объектов от текущего уровня вверх, и найдет наиболее специфичный
footer. Шаблоны могут вкладываться в шаблоны, а потому, если дизайнер
захочет изменить footer для текущего уровня (и вниз по дереву), ему нет
нужды копировать весь footer - достаточно создать более специфичный footer,
поставив в нем ссылку на footer более высокого уровня. Это существенно
облегчает обслуживание сайта и внесение изменений - изменения не надо
вносить во все копии по причине отсутствия копий - изменения вносятся туда,
где они нужны, дальше они "сами" разбегутся вниз по дереву.
Меанизм интерпретации шаблонов включает в себя почти полную поддержку
языка Питон, а это значит, что в шаблонах можно использовать условные
операторы, циклы, стандартные библиотеки.
Важный механизм всякого сложного Интернет-приложения - безопасность.
Механизмы security в Zope тоже есть, и они активно используют
"наследование". Например, генеральный менеджер сайта может определить
список менеджеров, каждый из которых отвечает за один подраздел. Каждому
из менеджеров даются права, и они, в свою очередь, часть этих прав могут
передать ниже по дереву - определить дизайнеров, которым доступна только
часть того, чем "владеет" менеджер подраздела.
Система безопасности Zope основана на понятии "роли". Несколько заранее
подготовленных "ролей" в Zope встроено (генеральный менеджер, менеджер,
анонимный посетитель), и определены механизмы создания новых ролей.
Zope практически целиком написан на Питоне (www.python.org).
Это делает сервер полностью переносимым. Разве что ДОС не может запустить
Zope (по причине отсутствия сокетов в ДОСовском питоне :)
С точки зрения CGI-писателей, почти полностью ориентированных на Перл,
это недостаток. Но я уже несколько лет пишу все на питоне - ДОСовские
утилитки, окошки для Windows, CGI и прочие программы для UNIX - и очень
доволен (и языком, и его реализацией, и библиотеками).
Помимо шаблонов Zope предоставляет стандартный способ извлечения данных
из SQL-серверов. Несмотря на хваленое единообразие SQL, сервера все-таки
сильно различаются друг от друга, и перенести комплекс CGI, ориентированный
на один сервер, на другой - задача сложная.
Zope предоставляет единообразный интерфейс и к SQL - не доводя его до
абсурда. то есть написать SELECT * FROM table все-таки можно, а значит
можно внести запросы, специфичные для одного сервера. Zope предоставляет
интерфейс, но не насилует им программиста.
Драйвера (точнее, адаптеры) имеются для всех SQL-серверов, для которых
Python имеет драйвера. ZSQL-адаптеры представляют собой надстройку над
драйверами, реализующую тот самый единообразный интерфейс. Есть драйвер для
программы gadfly (SQL-сервер, написанный целиком на питоне, а потому
переносимый на любую платформу), адаптеры Postgres и MySQL, Sybase, Oracle
и кто его помнит, что еще...
Механизм ZSQL Methods позволяет использовать SQL прямо в шаблонах, минуя
программирование на питоне.
Zope поддерживает "хранение" - persistence. Происходит это благодаря
записи объектов в специальную объектную базу данных. (Zope, будучи написана
на чистом объектно-ориентированном языке, сам весь из себя
объектно-ориентирован). Сохранение и восстановление данных для объектов
происходит практически прозрачно для программиста.
ОО-база имеет неограниченный буфер undo. Любое действие может быть
откачено. Например, отредактированный шаблон легко вернуть к предыдущему
состоянию.
Когда я последний раз что-нибудь об этом слышал, размер объектной базы
на www.zope.org (их WWW-сервер построен целиком на Zope) был более
гигабайта (со всеми дистрибутивами, файлами документации и пр.) и содержал
более миллиона объектов. В памяти (resident set size) сидело 15 мег. Этот
размер можно регулировать, меняя параметры кэширования -
увеличить/уменьшить размер кэша, время жизни объектов в кэше и пр.
Zope имеет свой собственный HTTP-сервер, так что его можно использовать
вообще без httpd. Но я предпочитаю статические документы отдавать Апачем, и
Zope умеет жить из-под любого WWW-сервера. Для связи используется маленький
переходничок Zope.cgi. Этот CGI, будучи запущен WWW-сервером, проверяет,
есть ли уже Zope в памяти (если нет - запускает его) и передает ему свое
окружение. Ждет ответ от Zope и передает их WWW-серверу.
Похоже на FastCGI? Да, это почти оно и есть, только называется PCGI -
Persistent CGI. Да, Zope постоянно живет в памяти, тем самым ускоряя
работу.
В настоящий момент ZHTTPServer - однопоточный, разговаривающий только на
языке HTTP (впрочем, на www.zope.org я не заметил никаких проблем, в том
числе и со скоростью). Сейчас проходит отладку ZServer - построенный на
асинхронных сокетах сервер, понимающий HTTP, FTP, WebDAV и PCGI. К нему
обещано дописать FastCGI и даже CORBA. И когда я говорю FTP - это вовсе не
значит, что Zope будет отдавать по FTP статические файлы. Нет, ZServer
отдает по FTP динамические объекты, по всем правилам Zope, с шаблонами,
security и прочим.
Еще один важный механизм Zope - версии. Версией назывется объект или группа объектов, или целое поддерево сайта, помеченное в ОО-базе как версия. Новая версия не видна посетителям сайта, и доступна программистам/дизайнерам для редактирования. В момент, когда разработчики завершат работу над обектом или поддеревом, версия объявляется завершенной, и Zope выставляет посетителям новую версию сайта.
Zope - это не цельный кусок софта, а набор компонент. Есть HTTP-сервер, его можно заменить Апачем. Есть механизм публикации динамических объектов (объекты пишутся на питоне). Есть ОО-база данных, в которых объекты могут хранить свои состояния. При изменении состояния буфер undo создается автоматически, поэтому не рекомендуется в этой базе держать часто меняющиеся данные, типа counter'ов. А механизм шаблонов я просто-таки использую на своих сайтах (его можно использовать совсем без Zope). Сочетание шаблонов и публикатора объектов приводит к классным эффектам - возникает возможность делать наследование имен (aquisition, не знаю, как это правильно по-русски сказать). Есть механизм интеграции с SQL; в том смысле интеграции, что SQL-запрос может стать частью шаблона. Это не совсем embedded SQL, дело в том, что ZTemplates - больше выполняемый код, чем статические шаблоны.