Systémy typu Allaire ColdFusion či Bea Weblogic nabízejí prakticky to samé co Zope. Nějaký prostředek k presentaci, vrstvu logiky a vrstvu pro ukládání dat. Díky tomu, že Zope je velmi modulární a otevřený systém, nabízí vám i něco navíc: ZPT a ZEO. Vezměme to ovšem pěkně popořádku.
Zope Page Templates (ZPT) nevznikly jako náhražka DTML, ale proto, že v některých případech je výhodnější některé věci dělat jinak. Pomocí DTML není žádný problém vytvořit jakýkoliv obsah (třeba obrázek nebo PDF dokument). Většinou ale vytváříme HTML stránku, kterou si nejprve připravíme (jako šablonu), pak do ní vložíme DTML a odladíme. Toho si všimli vývojáři a vytvořili produkt ZPT, který byl v některé z posledních verzí přijat jako oficiální součást systému.
ZTP umožňuje vytvářet HTML nebo XML (případně XHTML) obsah tak, že se dá později vytvořená šablona snadno znovu editovat WYSIWYG editory. Můžou tak spolupracovat profesionální designéři a programátoři dohromady. Designér vytvoří šablonu a programátor pomocí Template Attribute Language (TAL) dodá napojení na logiku. TAL je totiž jazyk postavený na XML a má svůj namespace (jmenný prostor). Jméno tohoto prostředí je „tal“ a jeho výhodou je, že WYSIWYG editory (Amaya, Dreamweaver…) jej ignorují. Když pak stránku s TAL atributy načte znovu designér, aby ji předělal, vše funguje naprosto bezvadně. Editor parametrům nerozumí, a tak je ponechá nedotčené. Navíc, pokud se rozhodnete již pro XHTML (Mozilla 1.0 i MS Internet Explorer 6 jej podporují), bude jak zdrojový kód šablony, tak i výsledek zcela korektní XML. Můžete tak použít jakýkoliv luxusní XML editor, který váš kód zcela jistě pěkně vybarví. Nemůžu si však odpustit jednu poznámečku: s úspěchem používám vim již řadu let a všem doporučuji totéž. Všechno to může vypadat například takto:
<html><head>
<title tal:content="template/title">Titulek</title>
</head><body>
<table tal:condition="container/objectValues"
border="1" width="100%">
<tr>
<th>Number</th>
<th>Id</th>
<th>Meta-Type</th>
<th>Title</th>
</tr>
<tr tal:repeat="item container/objectValues">
<td tal:content="repeat/item/number">#</td>
<td tal:content="item/getId">Id</td>
<td tal:content="item/meta_type">Meta-Type</td>
<td tal:content="item/title">Title</td>
</tr>
</table>
<p align=center>Adresa této stránky je
<span tal:replace="request/URL">adresa</span>.
</p></body></html>
Nejprve si tedy musíme vytvořit šablonu, a teprve potom ji pomocí TAL jazyka „vyplníme“. Například titulek má v šabloně fingovaný obsah „Titulek“. Ten ale uvidíme jen my nebo designér, který jej vytvořil, protože bude vždy změněn pomocí „tal:content“ na skutečný titulek, který je převzat z objektu „template“. Podobně je to se značkou tabulky. Ta se vyrendruje, pouze pokud bude pravdivý daný predikát. Pomocí „tal:repeat“ můžeme vyrendrovat řádky tabulky. Podobně můžeme volat skripty, ZSQL metody či jiné šablony. Jazyk TAL je poměrně propracovaný a obsahuje kromě jiného i definování maker (METAL jazyk), obsluhu chyb, zpracovávání formulářů a mnoho jiných drobností.
Jestliže v DTML bylo programování velice těžkopádné, tak v ZPT na něj úplně zapomeňte. Veškerá logika musí být někde jinde, což je dokonce výhoda, protože u větších projektů to vždy svádí napatlat všechno dohromady s tím, že se to „někdy“ rozhodí. Zřejmý je bezesporu fakt, že se ZPT programování svým přístupem výrazně odlišuje od již zaběhnutých standardů (PHP, ASP, Perl), v cěmž vidím malou překážku. Ne každý se chce učit něco zcela nového. Avšak po překonání bariéry se nám dostaví odměna v podobě přehledného a srozumitelného webového projektu.
Skripty, které na sebe přeberou logiku, můžete vytvářet v Pythonu nebo v Perlu. Můžete je volat přímo (pak se dá s výhodou využít URL traversing, který v některých případech pomůže eliminovat nepříjemné parametry), nebo ze stránek (objektů či šablon, chcete-li). Zope dohlíží také na bezpečnost, a tak skripty, podobně jako například java aplety, nemají příliš velká oprávnění. Většinou bez problémů stačí k jednoduchým úkonům a k propojení celého projektu. Jakmile ale potřebujete číst z disku či ořezávat obrázky pomocí nějaké pythonovské knihovny, musíte vytvořit takzvaný externí skript, který je třeba uložit do adresáře „lib“ a nelze jej editovat vzdáleně. Externí skript již může načítat standardní moduly Pythonu (Perlu) a jistě víte, že se na interenetu nacházejí monumentální archivy již hotových modulů úplně na všechno. Samozřejmostí (u velkých projektů nutností) je možnost vytváření vlastních modulů. V Zope tutoriálu například pomocí externí metody naučíte svou aplikaci komunikovat se servery Jabber. Milé, že?
Problémem dnešních internetových aplikací je škálovatelnost. Jakmile se provoz aplikace vyšplhá na desítky až stovky připojení za vteřinu, server trpí a jeho výpadky se stupňují. Toto se týká nejen Zope, ale prakticky všech webových systémů (pokud tedy nemáte v servrovně nějaké komerční řešení od firem Sun či IBM). Tyto problémy se často řeší používáním více počítačů. Ovšem skloubit akci několika serverů není žádná sranda. Jistě víte, že při řešení takovýchto situací létají éterem taková slova jako load-balancing, clustering, beowulf či enterprise. Člověk aby měl hlavu jako škopek. V Zope na tohle všechno zapomeňte.
ZEO (Zope Enterprise Objects) je komplexní řešení pro tvorbu serverového pole. Sestává z centrálního datového skladu (ZEO Storage Server) a z klientů obsluhujících jednotlivé uživatele (ZEO Clients). Servery mezi sebou komunikují internetovými protokoly, takže nejste ničím omezováni (zejména ne vzdáleností). ZEO se instaluje jako každý jiný produkt. Po nainstalování se klienti připojí na centrální server. V ovladacím panelu klienta tedy vidíte obsah, který je na centrálním serveru. Všechny akce včetně kešování, sessions či spouštění skriptů se ale odehrávají již na těchto klientech. Centrální server zároveň může fungovat i jako klient a přímo odpovídat na http požadavky.
Největší problém tkví v rovnoměrném rozložení zátěže na jednotlivé servery. Můžeme to řešit jednoduše tak, že centrální server si při vstupu do aplikace vybere jeden ze svých klientů (náhodně, geograficky…). Dá se použít i jednoduchý round-robin pomocí DNS serveru. Pro maximální výkon doporučuje dokumentace vyzkoušet Layer4 přepínače Cisco (nebo použít softwarovou emulaci pomocíLVS).
Systém ZEO je rychlé a jednoduché řešení, pokud váš server již nestačí s dechem. Musíte však počítat s tím, že aplikaci je nutno řádně odzkoušet. Při použití ZEO totiž trvá uložení do objektové databáze o mnoho déle. Aplikaci to sice nebrzdí, avšak mnohem častěji se mohou objevovat konflikty, kdy se dva klienti pokoušejí modifikovat ve stejnou dobu jeden objekt. Pokud ale používáte relační databázi a objekty v systému Zope měníte jen výjimečně, nebude vám to vůbec překážet.
Poslední věcí, o které jsem se nezmínil, je ZCatalog, který umožňuje vyhledávat objekty v Zope databázi. ZCatalog se podle dokumentace dá používat jako objektová databáze, dají se v něm tvořit vyhledávací indexy a umí dokonce fulltext. Musím se příznat, že jsem ZCatalog ještě nepoužil a ani se na to v nejbližší době nechystám. Veškerou svou práci totiž odvádím na poli relačních databází.
Myslím, že si Zope zaslouží větší pozornost webových vývojářů, a proto jsem napsal tento rozsáhlý článek. Nesnažil jsem se Zope v ničem srovnávat s konkurencí, pouze jsem chtěl ukázat, co všechno umí a že tu je. Podle mého názoru je to jasná jednička v open-source projektech pro tvorbu intranetů malých firem běžících například na windowsové platformě nebo s malým linuxovým serverem. Instalace je totiž snadná a rychlá, správa nulová, rychlost vývoje vynikající, možnost týmové spolupráce (bez pomůcek typu CVS) také není k zahození a stabilita celého produktu je velmi dobrá.
Pokud jste dočetli až sem, chtěl bych vám poděkovat a zároveň vás o něco požádat. Pokud jsem vás svým článkem oslovil a rozhodl(a) jste se na Zope blíže podívat či vyzkoušet, zanechte mi prosím v mé schránce e-mail. Snad mě to motivuje k dalšímu povídání o Zope a jeho produktech.
ČLÁNKY DO MAILU