Руководство по работе с продуктом installtool:

Постановка задачи и способ решения:

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

Подобный процесс установки может стать настоящим мучением, особенно в том случае, когда последовательность установки компонентов не является достаточно документированной, а компоненты при этом являются так или иначе зависимыми друг от друга: установка компонента A требует установки компонентов B и C, а компонент С в свою очередь не может работать без компонента D.

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

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

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

Все вышеуказанные проблемы легко решаются благодаря использованию продукта компании "Ключевые решения" installtool.

Цель installtool - предоставление средств, которые позволят произвести настройку объектной среды "одним кликом".

Основные понятия и принципы работы:

Продукт installtool предназначен для автоматической настройки объектной среды внутри сервера приложений Zope3 (т.е. копирование файлов в нужные папки lib/python и etc/site-packages придётся все-же сделать руками).

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

Каждый из скриптов декларирует цель и свои зависимости. Скрипт может достичь цели посредством некоторого реализованного в нем алгоритма, если удовлетворены его зависимости. Удовлетворение зависимостей есть цель других скриптов. Именно поэтому в директиве script продукта installtool для каждого выполняемого при установке скрипта следует указывать его имя (собственную цель) и список имен других скриптов (список зависимостей).

Скрипты могут декларироваться в любом порядке, потому что перед их выполнением будет выполнена сортировка по зависимостям, которая может привести к нескольким результатам:

Сортировка успешна

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

Сортировка провалилась

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

                    Ошибка
                    Не могу разрешить зависимости в одном из следующих скриптов:
                    имя_скрипта1 зависит от [u'имя_скрипта2']
                    имя_скрипта2 зависит от [u'имя_скрипта1']

Сортировка провалилась

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

                    Несуществующая зависимость!
                    Unknown dependency имя_скрипта1 of имя_скрипта2

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

Синтаксис и семантика zcml-инструкций:

Как было сказано выше, продукт installtool позволяет при написании инсталляторов использовать некоторый набор zcml-директив, упрощающих работы по настройке внутриобъектной среды.

На написание скриптов есть одно важное соглашение: installtool создает корневой объект и все работы по настройке и созданию объектов должны выполнятся скриптами должны выполнятся только внутри этого контекста. Это соглашение между разработчиками возникло из-за того, что малейшие попытки его нарушения вызовут страх пользователей перед "порчей" системы от запуска скриптов, корректирующих ее в заведомо неизвестной среде. Вероятность ошибок при этом крайне высока, а их диагностика - практически невозможна.

Поэтому никогда не меняйте ничего вне переданного в скрипт контекста.

Директива browser:factoryform :

Директива browser:factoryform включает в себя несколько атрибутов и поддирективу >. Список атрибутов следует ниже:

name

уникальное имя создаваемой фабрики. Сама фабрика с указанным именем будет создана как класс в модуле installtool.factories. Таким образом, полным именем фабрики будет указание полного пути к ней в виде installtool.factories.имя_фабрики.

root

корневой объект процедуры инсталляции: прежде всего создаётся он, и только потом всё остальное.

schema

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

for

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

view

url формы.

title

заголовок формы и метка для меню.

description

описание формы.

permission

права доступа на вызов формы.

Вложенные директивы property (их может быть столько, сколько надо), задают константы для установки, которые будут переданы скриптам установки в виде параметров с соответствующими именами и значениями. Атрибуты директивы property:

name

имя параметра, который будет передаваться в установочные скрипты

value

значение передаваемого параметра

Пример директивы :

                <browser:factoryform
                   name="demo" 
                   root="zope.app.folder.folder.Folder"
                   schema=".interfaces.IDemo" 
                   for="*" 
                   view="calldemo.html"
                   title="Demo" 
                   description="Demo Demo"
                   permission="zope.ManageContent">
                 <property name="par1" value="11"/> 
                 <property name="par2" value="12"/>
                 <property name="par2" value="12"/> 
                 <property name="par4" value="14"/>
                 </browser:factoryform>

К директиве декларции фабрики следует добавить набор директив, декларирующих скрипты, используемые этой фабрикой. Для декларации используется директива dt>

Пример :

               <script
                   factory="demo"
                   name="C"
                   requires="B"
                   script=".scripts.scriptC"
                   />

Пример использования:

В качестве конкретного примера, а также для иллюстрации вышесказанного, рассмотрим пример использования продукта installtool для установки сайта, состоящего из некоторой папки, внутри которой расположены 20 других папок с именами вида name000, name001, ..., name019. Всё это, как и заявлялось, будет реализовано минимальным числом кликов.

Для того, чтобы наглядно увидеть демонстрацию возможностей installtool на примере продукта demo, возьмите исходники продукта installtool по адресу:

            http://code.keysolutions.ru/svn/installtool/trunk/installtool/

Содержимое папки demo и есть продукт, написанный на основе installtool. Скопируйте файлы из папок installtool/etc и installtool/demo/etc в папку ZOPE_INSTANCE/etc/site-packages. Запустите zope, зайдите в него.

Для определённости перейдите в корневую папку. В меню "Добавить" слева найдите пункт Demo, щёлкните по нему. На экране появится форма, сгенерированная на основе полей схемы installtool.demo.interfaces.IDemo. Данные в полях можно оставить без изменения, так как на дальнейшую установку их значения не влияют, и они используются лишь в иллюстративных целях. Для определённости, впишите в поле "Название объекта" значение Root и нажмите кнопку "Добавить". На этом действия по установке продукта завершены!

В корневой папке найдите папку с именем Root, зайдите в неё, убедитесь, что внутри расположены 20 папок с требуемыми именами. Сравните затраченное на это время со временем, которое вы затратили бы на создание подобной структуры папок руками и сделайте соответствующие выводы.

Поясним проделанное. Зайдите в папку demo. Основными файлами продукта, помимо __init__.py и add.py, являются, как вы видите, configure.zcml, содержащий набор описанных выше директив, interfaces.py, содержащий схемы используемых форм и файл scripts.py, содержащий, собственно, скрипты, производящие установку.

Как видно, для проделывания необходимых действий использовались лишь директивы factoryform и script. Все поля директивы factoryform подробно описаны выше и проблем с пониманием их использования возникнуть не должно.

Проанализировав директивы script можно легко увидеть. что установка происходит четырьмя скриптами с именами scriptA, scriptB, scriptC, программный код которых расположен в файле scripts.py. Обратите внимание, что в файле scripts.py смысл имеет лишь код скрипта A, а остальные указаны в иллюстративных целях для проверки контроля зависимостей между скриптами.

Из файла configure.zcml видно, что скрипт A нельзя выполнять до выполнения скрипта С, а скрипт C нельзя выполнять до выполнения скрипта B. Скрипт B не требует выполнения никаких других скриптов. Видно, что скрипты расположены не в том порядке, в каком их следует выполнять, однако, благодаря использованию топологической сортировки, скрипты вызываются на выполнение в единственно безошибочной последовательности: B, C, A.

Файл interfaces.py содержит описание схемы (в данном случае одной), используемой для генерации формы добавления нашего демонстрационного продукта.

Вот и всё!

Заключение:

Как видно из документа и приведённых в нём примеров, использование продукта installtool позволяет существенно сократить время, затрачиваемое на установку программного обеспечения под Zope3, что повышает удобство как разработчика, так и человека, который будет устанавливать тот или иной продукт.

Планы на будущее:

Продукт по мере сил совершенствуется, и на сегодняшний день можно выделить следующие направления его дальнейшего развития:

• Реализовать возможность объединения двух и более инсталляторов в один, что особенно актуально при установке сложной системы, состоящей из большого числа продуктов, каждый из которых имеет собственную процедуру инсталляции.
• Проработать возможность исключения подцелей на этапе установки. Это может быть достаточно полезно, когда нет необходимости устанавливать систему целиком, а требуется лишь установка части элементов объектной среды будущей системы для установки версии с ограниченной функциональностью.
• Сделать возможность создания "пакетов" скриптов, т.е. скриптов, которые объединяются не по явным названиям, а по абстрактным целям. Это позволит иметь некоторую взаимозаменямость скриптов при установке разных продуктов в систему. Например, можно будет иметь форму "Создать Сайт" которая создаст такой сайт, который позволяют продукты, установленные в системе.

Следите за нашими обновлениями!