Zope – це дуже-дуже старий фреймворк (історія почалася ще з 1995), але деякі його частини, а іноді і сам він використовуються в різних системах і досі. Наприклад Twisted використовує інтерфейси Zope (їх свідчення). Біда з ним в тому, що якась пристойна інструкція в інтернеті не доступна. Може вона й була там колись, але на жаль посилання не завжди працюють, а з такою старовиною як Zope – дуже часто ведуть в тупик 404. Своїм трактатом постараюсь цю біду хоч трохи виправити.

Ах, ще цікавий факт, ZCA з’явилась в Zope 3 (BlueBream), при спробі переписати все “правильно”, ігноруючи зворотню сумісність. Таким чином ситуація трохи нагадує ситуацію з Python 3. Тільки Python 3 з’явився в 2008, і здається таки має деякі шанси вижити, а от Zope 3 (BlueBream) – в 2004, і від нього відросли інші фреймворки, наприклад BFG, який об’єднався з Pylons і став Pyramid. Але цю всі історію дуже цікаво розповідає Пол Еверітт, один з тих хто все це почав. Він пояснить вам що Zope ще не вмерла, вона просто спить:

А тут мова піде лише про таку частинку Zope, як ZCA. І ми будемо писати код. З нуля!

Термінологія

Але почнемо з теорії, аби розуміти що збираємось писати.

• Zope – Z Object Publishing Environment – фреймворк і веб-сервер які намагались публікувати у вебі об’єкти, ще в ті часи коли Apache віддавав статичний HTML і ганяв CGI скрипти. Шлях в URL в ньому відповідає не шляху до файлу зі скриптом, а шляху в ієрархії об’єктів. Кажуть то був прорив.
• Компонент (Component) – якийсь код на Python, зазвичай клас, що реалізує інтерфейс. Компоненти поділяються на адаптери та утиліти (див. нижче).
• Інтерфейс (Interface) – спеціальний клас, єдиною метою якого є опис функціоналу що реалізується іншим класом чи модулем. Вони реєструються в реєстрі компонент, і до цього реєстру можна робити запити “Дайте мені будь-ласка компоненти що реалізують оцей інтерфейс”. Класи можуть декларувати що вони реалізують (implement) певний інтерфейс. Екземпляри цих класів тоді надають (provide) цей же інтерфейс.
• Сервіс (Service) – це об’єкт що працює з компонентами. Думайте про компоненти як про “речі”, а про сервіс – як про частину коду що бере ці “речі” і робить з ними щось корисне.
• Реєстр компонентів (Component registry, також Site Manager) – база даних компонентів та інтерфейсів, сервіс за означенням вище. Якщо ви реєструєте компоненти в реєстрі, вони стають доступними для інших користувачів того ж реєстру. Існує глобальний реєстр компонентів що створюється автоматично, і можна використати ZODB як локальний реєстр.
• ZODB – ZOpe Object Database – база даних об’єктів Zope. Використовувати її з компонентами не обов’язково, тому про неї якось іншим разом.
• Глобальний реєстр компонентів (global component registry) – сервіс що автоматично створюється коли ваша програма що містить компоненти Zope запускається і наповнюється компонентами що описані в конфігураційних файлах ZCML. До глобального реєстру можна отримати доступ з будь-якого місця програми. Коли програма завершує роботу всі зміни внесені до глобального реєстру зникають і при наступному запуску він заново завантажується з ZCML.
• Локальні компоненти (Local components) – це компоненти що не створюються в глобальному реєстрі компонентів. Зазвичай їх зберігають в ZODB, що також означає що вони персистентні, тобто можуть пережити перезапуск програми.
• ZCML (вимовляється “зе-кемел”, Zope Configuration Markup Language) – XML файли, що описують компоненти які потрібно зареєструвати в глобальному реєстрі.
• Адаптери (Adapter)- це класи що дозволяють використовувати з об’єктом нові інтерфейси. Клас адаптера містить виклик adapts() який вказує інтерфейс що адаптує адаптер, що означає що ви можете передати будь-який об’єкт, що реалізує цей інтерфейс, в метод __init__ класу адаптера, наприклад a = myAdapter(myobject). Тепер MyAdapter бере на себе обов’язок фронт-енда для myobject, таким чином, що будь-який інтерфейс реалізований за допомогою myAdapter, буде правильно працювати з myobject. В певному сенсі адаптер “огортає” адаптований об’єкт.
• Фабрика (Factory) – це щось (якщо конкретніше, не щось, а утиліта, визначення якої буде нижче), яка створює компоненти та об’єкти. Це як більш високорівнева версія конструктора. Фабрика має бути об’єктом який можна викликати, і повинна реалізувати інтерфейс IFactory. Фабрики надають зручні засоби для доступу до конструкторів компонентів через реєстр компонентів, а не прямим викликом конструктора. Важливо зауважити що ZCM автоматично створює фабрики, коли ви реєструєте компоненти. В багатьох випадках це означає що ви не матимете справи зі створенням фабрики напряму.
• Утиліта (Utility) – об’єкт який ви хочете додати до реєстру компонентів. Вона може бути будь-яким об’єктом мови Python, який може знадобитись іншій частині програми. Утиліта повинна реалізовувати принаймі один інтерфейс.

Я знаю що ви з цього словника майже нічого не зрозуміли. Не бійтесь, я теж. Далі ми розберемо це на практиці, і ситуація проясниться.
Read more »