Oleg Brojtman. Zope - The Object Publishing Environment
Zope - The Object Publishing Environment
Avtory:
Oleg Brojtman <phd@mail.ru> i
Russkoyazychnaya Gruppa Polzovatelej Python i Zope <python@list.glasnet.ru>.
PREAMBULA - trudnosti perevoda v Zope
---------
Vo-pervyh, samo nazvanie. Formal'no ono zvuchit kak Z Object i tak dalee.
Esli napisat' The Object - ono dolzhno byt' Tope, no eto oznachaet
"p'yanstvovat'". Tak chto ne u odnih russkih s etim slovom problemy.
Vo-vtoryh, transkripciya ili transliteraciya - Zop? Zope? v Zope? Poslednij
variant u nekotoryh rozhdaet nepodobayushchie mysli i associacii :) YA
predpochitayu pisat' Zope i proiznosit' Zop. On, v konce koncov, server!
--------
Zope (www.zope.org) - eto ob容ktno-orientirovannaya platforma, server
prilozhenij, prednaznachennyj dlya sozdaniya dinamicheskih web-prilozhenij i
interaktivnyh sajtov.
U vyrazheniya "ob容ktno-orientirovannyj" zdes' neskol'ko storon.
Vo-pervyh, Zope napisan na yazyke Python, ob容ktno-orientirovannom yazyke so
mnozhestvennym nasledovaniem.
Vo-vtoryh, Zope postroen vokrug idei "publikacii ob容ktov" - URL, k
kotoromu obrashchaetsya brauzer, yavlyaetsya ssylkoj na ob容kt (ekzemplyar klassa),
vyzyvaemyj na vypolnenie.
V-tret'ih, sami ob容kty (serializovannye ekzemplyary klassov) hranyatsya v
ob容ktno-orientirovannoj baze dannyh ZODB.
V dal'nejshem ya budu prodolzhat' upotreblyat' vyrazhenie
"ob容ktno-orientirovannyj" dostatochno chasto, ne potomu chto eto modnoe
slovo, a potomu chto neot容mlemoe svojstvo Zope.
Eshche odno neot容mlemoe svojstvo - modul'nost'. Zope - eto ne cel'nyj
kusok softa, a bogatyj nabor modulej, nazyvaemyh komponentami. "Komponent" -
eshche odno slovo, kotoroe ya budu chasto upotreblyat'.
Drugie modnye slova, tipa XML, ya budu upotreblyat' rezhe. |to ne znachit,
chto Zope ne rabotaet s XML - rabotaet eshche kak, - prosto k moemu vvedeniyu
eto ne imeet otnosheniya, a ya starayus' "ne upotreblyat' slova tol'ko za to,
chto oni krasivye i dlinnye" (C) Kerroll, perevod Demurovoj).
Eshche neskol'ko modnyh slov, imeyushchih otnoshenie k delu: free software, open
source, 64-bit (na sootvetstvuyushchih OS), mnogoplatformennost' i
perenosimost' (Zope napisan na portabel'nom yazyke Piton i rabotaet vo vseh
yuniksah i v Windows; osnovnoj format bazy dannyh ZODB - fajl Data.fs -
polnost'yu nezavisim ot platformy i OS), masshtabiruemost' i raspredelennost'
(s pomoshch'yu komponenta ZEO, o chem pozzhe).
Itak...
------
Protokoly WWW (HTTP, CGI i t.d.) chasto neadekvatny zadacham i mogut
delat' publikaciyu dinamicheskih dannyh neopravdanno slozhnoj. Ih nizkij
uroven' nedostatochen dlya neposredstvennogo sozdaniya mnogih klassov
web-prilozhenij na ih osnove.
Zope sozdaet ob容ktno-orientirovannuyu obolochku vokrug etih
nizkourovnevyh sredstv. S ego pomoshch'yu reshenie zadachi proishodit obychnym
putem - programmist pishet nabor ierarhij klassov, yavlyayushchijsya abstrakciej
predmetnoj oblasti, a Zope beret na sebya trud po predostavleniyu dostupa k
ekzemplyaram etih klassov.
------------
C Zope rabotayut sleduyushchie kategorii pol'zovatelej:
** administrator hosta - kompiliruet i installiruet programmy i
dopolnitel'nye komponenty
** programmist - pishet komponenty, to est' klassy, na yazyke Python
** webmaster - rasstavlyaet eti komponenty (to est' ekzemplyary klassov) na
sajte, pol'zuyas' menedzherskim web-interfejsom
** administrator sajta - zavodit zapisi o pol'zovatelyah, sozdaet roli,
stavit ih v sootvetstvii drug drugu, naznachaet komu (kakoj roli) k
kakim ob容ktam mozhno imet' dostup, i kakoj imenno dostup (sozdanie
ob容kta, redaktirovanie, udalenie, prosmotr i t.d.)
|to, konechno, ne obyazatel'no raznye lyudi - eto roli. Na malen'kom sajte
eti roli mozhet vypolnyat' odin chelovek. Dlya bol'shih sajtov Zope predostavlyaet
mehanizmy delegirovaniya polnomochij administratoram uchastkov sajtov,
verstal'shchikam, redaktoram.
----------
Zope Core
V "serdce" Zope nahoditsya ORB (object request broker), a takzhe
mehanizmy, obespechivayushchie poisk (ZCatalog), bezopasnost', kollektivnuyu
rabotu i razdelenie informacii. Zope imeet web-interfejs dlya
programmirovaniya i administrirovaniya.
ZServer
Mnogopotochnyj ZServer predostavlyaet gibkij mehanizm svyazi, podderzhivaya
protokoly HTTP, FTP, XML-RPC, FastCGI i PersistentCGI. Zope mozhet byt'
zapushchen s ZServer, prichem mozhno ispol'zovat' ZServer sovmestno s uzhe
sushchestvuyushchim WWW serverom; ili zhe Zope mozhno zapustit' iz-pod sushchestvuyushchego
WWW servera v rezhime PCGI (odnopotochnyj server PersistentCGI).
Object Database (ZODB)
Ob容ktno-orientirovannaya baza Zope hranit ob容kty (imenno ob容kty v
smysle Python, to est' serializovannye ekzemplyary klassov); sama ZODB
napisana ob容ktno-orientirovanno, to est' kak nabor derev'ev klassov. V
ZODB mozhno proizvol'no menyat' klass StorageManager - hranilishche. Standartnoe
hranilishche FileStorage hranit dannye v fajle Data.fs, no mozhno ispol'zovat'
al'ternativnye klassy - SQLStorage ili BerkeleyStorage. ZODB podderzhivaet
atomarnye operacii (tranzakcii), neogranichennyj undo (tol'ko s
sootvetstvuyushchim hranilishchem, naprimer, FileStorage ili InterbaseStorage
podderzhivayut Versii i otkat, a ostal'nye hranilishcha - net), privatnye
Versii, i masshtabiruetsya do gigabajtov hranimyh dannyh. Otdel'nyj mehanizm
ZEO (Zope Enterprise Option) pozvolyaet povysit' nadezhnost' i
masshtabiruemost' putem klasterizacii. Sobstvenno, yadrom ZEO yavlyaetsya eshche
odno hranilishche ServerStorage, kotoroe obrashchaetsya ne k lokal'nomu Data.fs, a
k udalennomu serveru; vtorym komponentom ZEO yavlyaetsya kak raz server.
Document Template Markup Language (DTML)
Za etim nazvaniem skryvaetsya bogatyj mehanizm interpretacii (renderinga)
shablonov. Prostye sajty mozhno sozdavat', voobshche ne obrashchayas' k Pitonu - na
odnom DTML (estestvenno, pol'zuyas', uzhe gotovymi komponentami Zope).
Integraciya s relyacionnymi SUBD
Zope imeet uroven' abstrakcii ZSQL, pozvolyayushchij legko integrirovat'
sistemu s SQL, bud' to PostgreSQL, Oracle, MySQL ili ODBC.
Produkty Zope
Produkty - komponenty, napisannye programmistom na Pitone - pozvolyayut
dopolnyat' Zope novymi tipami ob容ktov. Naprimer, komponent (nazovem ego
uslovno Poll) dlya sozdanii na sajte golosovanij. Posle togo, kak
programmist napishet sootvetstvuyushchie klassy, webmaster rasstavit ekzemplyary
etih klassov na sajte i sozdast kazhdomu iz ekzemplyaru dizajn; redaktor
sajta napolnit ih soderzhimym (vopros i spisok otvetov dlya kazhdogo
ekzemplyara); i posetiteli sajta mogut nachinat' golosovat'!
ZClasses
Z-Klassy - eto mehanizm programmirovaniya "myshkoj", programmirovanie bez
programmirovaniya. Z-Klassy ne trebuyut znaniya programmirovaniya, i v to zhe
vremya pozvolyayut sozdavat' novye tipy dannyh (komponenty) cherez web.
Sozdannye programmistom Z-klassy legko rasprostranyayutsya i ustanavlivayutsya.
--------
Programmistu:
-- mehanizm shablonov (DTML)
-- nabor komponentov (ZODB, ZCatalog i prochie)
-- API dlya sozdaniya svoih komponentov
-- API dlya dostupa k Zope minuya www-interfejs, pryamo po HTTP i/ili
XML-RPC
-- nekotorye bazovye komponentov (Zserver, ZPublisher, ZODB, DTML,
Catalog) mozhno ispol'zovat' voobshche vne Zope, prosto v programmah
na Pitone
web-masteru:
-- mehanizm shablonov (DTML)
-- www-interfejs dlya upravleniya sajtom
administratoru:
-- www-interfejs dlya upravleniya sajtom
-- prostoj, i v to zhe vremya moshchnyj instrumentarij dlya
administrirovaniya pol'zovatelej, prav i prochih mehanizmov
bezopasnosti
PROGRAMMIROVANIE dlya Zope
----------------
Programmirovanie dlya etoj slozhnoj i gibkoj platformy osushchestvlyaetsya
raznymi mehanizmami i na raznyh yazykah.
1. Programmirovanie na DTML. |to ne stol'ko programmirovanie, skol'ko
verstka, rabota webmastera. Iz DTML dostupno bol'shoe chislo funkcij i
ob容ktov Pitona i Zop, za isklyucheniem teh, kotorye skryty po soobrazheniyam
bezopasnosti. DTML prednaznachen preimushchestvenno dlya prezentacii, a ne dlya
manipulyacii dannymi.
2. PythonMethods. Kod pishetsya na Pitone i vvoditsya cherez web-interfejs
Zope. Na etot kod rasprostranyayutsya te zhe ogranicheniya bezopasnosti,chto i na
DTML. Obychno PythonMethod - odna ili neskol'ko prostyh funkcij.
3. ExternalMethods. |to tozhe kod na Pitone, i tozhe obychno neskol'ko
svyazannyh funkcij. Na etot kod ne rasprostranyayutsya ogranicheniya bezopasnosti
(v tom smysle, chto etot kod imeet dostup ko vsem funkciyam, tipam i klassam
Pitona i Zope, no sam etot kod mozhno zashchitit' ot dobavleniya ili
ispol'zovaniya sredstvami bezopasnosti Zope), i stavitsya on v fajlovuyu chast'
Zope rukami administratora hosta, a potom dobavlyaetsya v ierarhiyu ob容ktov
Zope cherez web-interfejs.
4. Komponenty. Oni pishutsya na Pitone s pomoshch'yu Product API. Komponent -
eto klass ili nabor derev'ev klassov. Nikakih ogranichenij po bezopasnosti
(v uzhe ukazannom dlya ExternalMethods smysle; ispol'zovanie zhe metodov
komponenta mozhet byt' zashchishcheno sovmestnymi usiliyami programmista i
administratora sajta). Kod etot stavitsya v fajlovuyu sistemu administratorom
hosta, i Zope prihoditsya perezapuskat'. Posle etogo v spiske Produktov
poyavlyaetsya novyj Produkt (a to i ne odin, esli programmist ili
administrator hosta razom inicializiruet neskol'ko Produktov ili v odnom
Produkte registriruet neskol'ko Proizvoditelej (konstruktorov)), ekzemplyary
kotorogo mozhno sozdavat' v lyubom meste ierarhii ob容ktov.
4. ZClass. "Programmirovanie myshkoj". Sozdatel' Z-klassa raspisyvaet,
kakie u ob容kta est' atributy, i sozdaet na DTML sposoby redaktirovaniya i
pokaza ekzemplyarov klassa. Vse "programmirovanie" idet cherez web-interfejs
Zope. Z-Klass dobavlyaetsya v spisok Produktov, i mozhno sozdavat' ego
ekzemplyary. Pri izmenenii programmistom Z-klassa vse ekzemplyary menyayutsya
avtomaticheski (to est' ekzemplyary soderzhat ne kopiyu koda, a ssylku na
klass). Z-Klassy mozhno nasledovat' ot bogatogo bazovogo nabora klassov
Zope, mozhno ot drugih Z-klassov, i programmist mozhet sozdat' Komponent,
vklyuchayushchij klassy, ot kotoryh mozhno nasledovat' Z-klassy.
-------------------
Zope publikuet Pitonovskie ob容kty (ekzemplyary klassov). Dlya etogo v
Zope est' komponent ZPublisher - broker ob容ktnyh zaprosov. Poluchiv zapros
(ot ZServer'a, kotoryj v svoyu ochered' poluchaet zapros iz vneshnego mira po
odnomu iz podderzhivaemyh protokolov), on:
-- nahodit v ierarhii ob容ktov ob容kt, k kotoromu proishodit obrashchenie
-- preobrazuet vhodnye dannye v sootvetstvuyushchie tipy dannyh Pitona
(berutsya dannye iz form ili zaprosa GET, kuki; vse upakovyvaetsya v
obshchee prostranstvo imen)
-- proveryaet autentifikaciyu i avtorizaciyu
-- vyzyvaet najdennyj ob容kt s parametrami, buferizuet otvet (vklyuchaya
kod otveta, kuki i prochie zagolovki otveta HTTP) i vozvrashchaet klientu
otvet
Bez pomoshchi so storony programmy ZPublisher, konechno, ne mozhet
osushchestvit' podhodyashchie preobrazovaniya tipov, poetomu avtor mozhet ukazat', v
kakom vide on hochet poluchit' dannye. Vot primer formy dlya zapolneniya, s
ukazaniyami, zashitymi v imena polej:
<FORM name="formA" action="myObject" method="POST">
<input type="text" name="age:int" size="2">
<input type="checkbox" name="category:int:list">K1
<input type="checkbox" name="category:int:list">K2
<input type="submit" name="manage_setAge:method" value="Ustanovit'">
<input type="submit" name="manage_delete:method" value="Udalit'">
</FORM>
Posle zapolneniya formy v brauzere i nazhatiya odnoj iz knopok ZPublisher
preobrazuet vvedennye dannye. Peremennaya age preobrazuetsya v celoe,
checkbox'y - v spisok celyh, i vyzovetsya odin iz metodov ob容kta myObject v
zavisimosti ot nazhatoj knopki.
Proverka, estestvenno, osushchestvlyaetsya na storone servera, v Zope. Esli
peremennaya age ne preobrazovyvaetsya v celoe, vozniknet oshibka. Ee mozhet
obrabotat' publikuemyj ob容kt, a net - Zope vydast pol'zovatelyu HTML s
tekstom ob oshibke. Dlya proverki na storone klienta mozhno ispol'zovat'
JavaScript. Iskrivlennye imena slegka meshayut dostupu iz JS, no eto ne
smertel'no: element = document.forms["formA"].elements["age:int"]
Kak imenno vyzovetsya metod, zavisit ot ego (metoda) signatury (v Pitone
vsya informaciya o kode dostupna vo vremya vypolneniya). Naprimer, esli
myObject - ekzemplyar vot takogo klassa:
class AgeManager:
def view(self, age=None):
if age is None:
age = self.age
return "Vozrast: <b>%d</b>" % age
def manage_setAge(self, age):
self.age = age
def manage_delete(self, category):
for c in category: self.delete(c) # self.delete ne pokazan
to metod manage_setAge vyzovetsya s celym age, ili manage_delete - so
spiskom nazhatyh checkbox'ov. Ostal'nye peremennye formy mozhno izvlech' iz
obshchego prostranstva imen, dostupnogo cherez self.
Publikaciya cherez metod GET i togo proshche: na zapros
http://www.my.server/root/subobject/sub2/myObject/view?age:int=12
ZPublisher obhodit ierarhiyu ob容ktov (travers s uchetom mehanizma
acquisition, o chem pozzhe) i publikuet myObject - u ob容kta vyzyvaetsya metod
view s celochislennym parametrom.
ACQUISITION - zaimstvovanie vmesto nasledovaniya
-----------
Acquisition - eto mehanizm zaprosa znachenij peremennyh iz tekushchego
konteksta. Perevedem eto slovo kak "zaimstvovanie" atributov; otnositel'no
adekvatnyj perevod.
Zaimstvovanie znacheniya atributa proishodit iz konteksta ob容kta.
Kontekstov byvaet dva - staticheskij, voznikayushchij v moment sozdaniya ob容kta,
i dinamicheskij, voznikayushchij vo vremya vyzova metoda ob容kta na vypolnenie.
Otkuda imenno proishodit zaimstvovanie - etim upravlyaet programmist pri
sozdanii ili ispol'zovanii komponenta.
Kontekst - eto stek, v kotorom proishodit poisk atributa. Naprimer, esli
est' kontekst [object, sub2, myObject] (na vershine nahoditsya myObject), i
myObject zaprosil znachenie atributa color, to poisk budet proishodit' v
glubinu steka. Snachala atribut s takim imenem budet iskat'sya v myObject,
esli ego tam net - poisk perejdet k sub2, potom k object.
Staticheskij kontekst - eto put' ot kornya ZODB (ZODB, ne sajta!) k
ob容ktu v ierarhii ob容ktov. Dinamicheskij kontekst - eto put' (stek),
voznikayushchij vo vremya obhoda ierarhii ob容ktov komponentom ZPublisher pri
obrashchenii k ob容ktu cherez URL.
Naprimer, esli est' put' /root/object/subobject/myObject, to eto i est'
staticheskij kontekst (tochnee, kontekstom yavlyaetsya stek ob容ktov
[root, object, subobject, myObject]).
Dinamicheskij kontekst zavisit ot URL. Esli proizoshlo obrashchenie k adresu
http://www.server/root/object/subobject/myObject, to v etom sluchae
dinamicheskij kontekst sovpadaet so staticheskim. No pri obrashchenii k
http://www.server/root/english/object/subobject/myObject (gde english -
papka v ob容kte root) kontekst budet drugoj - v stek dobavitsya ob容kt
english. CHtoby ponyat', na kakoe imenno mesto englsih dobavitsya, nado
podrobno rassmotret' process traversa. ZPublisher sam tozhe ispol'zuet
mehanizm acquisition, tak chto v celom razbor adresa
http://www.server/root/english/object/subobject/myObject proishodit
sleduyushchim obrazom.
Poluchiv (ot ZServer'a) put' /root/english/object/subobject/myObject,
ZPublisher nachinaet obhodit' otdel'nye chasti puti, stroya po hodu stek.
Snachala stek pust, zatem k nemu dobavlyaetsya root (poisk nachinaetsya ot kornya
ZODB, i proveryaetsya, chto ob容kt s takim imenem est' v korne), zatem
ZPublisher obnaruzhivaet english i zaprashivaet ego (s uchetom zaimstvovaniya);
ob容kt obnaruzhivaetsya v /root i popadaet v stek, zatem idet object, kotoryj
zaimstvuetsya ne iz english, a iz /root, zatem normal'nym putem idut
subobject i myObject. V dannom sluchae stek prosto sovpal s URL. No esli by
v english byl svoj object, on by zaimstvovalsya by ottuda, a ne iz /root. I
esli by v etom object ne bylo subobject, to subobject opyat' zaimstvovalsya
by iz /root (eli on tam est'). V rezul'tate my imeli by kontekst (stek)
[/root, /root/english, /root/english/object, /root/subobject, myObject]. I
esli by myObject zaprosil atribut language, otsutstvuyushchij v
/root/subobject, on poluchil by ego iz /root/english/object, a ne iz
/root/object!
Takim obrazom, menyaya poryadok komponent v URL, programmist mozhet
sovershenno menyat' vid i soderzhanie sajta, ne dubliruya pri etom ogromnye
kuski koda ili teksta. Nado lish' proizvesti pravil'nuyu faktorizaciyu -
razbit' kod i oformlenie na nebol'shie ob容kty, i stroit' kontekst (on eshche
nazyvaetsya acquisition path - marshrut zaimstvovaniya znachenij atributov).
Rassmotrim podrobnyj primer. Dva osnovnyh ob容kta Zope - eto klassy DTML
Document i DTML Method, vklyuchennye v distributiv Zope. Oni prednaznacheny
dlya raznogo tipa ispol'zovaniya. DTML Document hranit soderzhanie, tekst; ego
put' - zaimstvovanie iz staticheskogo konteksta. DTML Method prednaznachen
dlya aktivnyh dejstvij, on zaimstvuet znacheniya iz dinamicheskogo konteksta.
Eshche est' klass Folder - papka. V nej hranyatsya drugie ob容kty.
Pust', skazhem, Dokument my.html nachinaetsya so standartnogo zagolovka, i
zakanchivaetsya standartnym podvalom. Na yazyke DTML eto vyrazhaetsya kak
<dtml-var standard_html_header> i <dtml-var standard_html_footer>.
Razmestim eti ob容kty na nebol'shom abstraktnom (to est' sushchestvuyushchim tol'ko
v nashih golovah) sajte. Pust' est' koren' (koren' v ZODB est' vsegda), v
nem neskol'ko papok, skazhem, Razdel1 i Razdel2, 2 Metoda - header i footer,
i v Razdel2 - nash my.html.
/
standard_html_header
standard_html_footer
Razdel1
Razdel2
my.html
Itak, brauzer obrashchaetsya k http://www.server/Razdel2/my.html. ZPublsiher
stroit kontekst [/, /Razdel2, /Razdel2/my.html] i vyzyvaet rendering
my.html. Tot nachinaet renderitsya, i v samom nachale vstrechaet
<dtml-var standard_html_header>. Zaprashivaetsya znachenie zagolovka. V
my.html takogo ob容kta net, v Razdel2 net, poisk perehodit v koren' - tam
takoj est'. On vypolnyaetsya (renderitsya), potom vypolnenie vozvrashchaetsya v
my.html, potom footer - vse.
Voz'mem i dobavim v Razdel2 drugoj header:
/
standard_html_header
standard_html_footer
Razdel1
Razdel2
standard_html_header
my.html
I opyat' obratimsya k http://www.server/Razdel2/my.html. Teper' my.html
pozaimstvuet drugoj header, i vyglyadet' budet po-drugomu!
Dobavim v koren' novyj razdel, s drugimi header/footer:
/
standard_html_header
standard_html_footer
Razdel1
Razdel2
standard_html_header
my.html
NewLook
standard_html_header
standard_html_header
I obratimsya k http://www.server/Razdel2/NewLook/my.html. Budet li
my.html ispol'zovat' header iz NewLook? Net! my.html - DTML Document, i
vsegda ispol'zuet staticheskij kontekst. Ego acquisition path vsegda
[/, /Razdel2, /Razdel2/my.html].
Dobavim v Razdel1 ob容kt DTML Method index.html
/
standard_html_header
standard_html_footer
Razdel1
index.html
Razdel2
standard_html_header
my.html
NewLook
standard_html_header
standard_html_header
I obratimsya k http://www.server/Razdel1/index.html. Poskol'ku eto Metod,
to budet ispol'zovan dinamicheskij kontekst, no v dannom sluchae on sovpadaet
so staticheskim. A vot pri obrashchenii k
http://www.server/Razdel1/NewLook/index.html dinamicheskij kontekst budet
drugoj, i index.html pozaimstvuet atributy iz NewLook - i budet vyglyadet'
po drugomu!
Izmenim sajt poslednij raz. Vse udalim,
/
standard_html_header
standard_html_footer
Razdel1
index.html
Razdel2
my.html
i otredaktiruem header/footer, tak chtoby oni vklyuchali na sajte, skazhem,
levuyu kolonku. Nazovem ee left-column, i sozdadim ee v korne i v razdelah:
/
standard_html_header
standard_html_footer
left-column
Razdel1
index.html
left-column
Razdel2
my.html
left-column
Teper' pri vyzove http://www.server/Razdel1/index.html budet
pokazyvat'sya odna kolonka, http://www.server/Razdel2/my.html - drugaya. A
header pri etom odin na vseh! Kak header znaet, kakuyu kolonku ispol'zovat'?
Ochen' prosto - on uchastvuet v poiske po acquisition path, po kontekstu
(staticheskomu ili dinamicheskomu v zavisimosti ot togo, otkuda ego vyzvali),
ne bolee togo.
|ti raznye left-column dazhe ne obyazany dazhe byt' ekzemplyarami odnogo
klassa. V korne eto mozhet byt' DTML Method, a v Razdel2 - ZNavigator.
Header'u vse ravno, kogo renderit', on vyzyvaet left-column, nichego ne znaya
ob ego tipe i ustrojstve (opyat' ob容ktno-orientirovannoe programmirovanie).
Eshche odin primer, blizhe k real'noj zhizni s Zope, no menee podrobnyj.
Predvaritel'noe zamechanie: kogda URL ssylaetsya ne na metod ob容kta, a na
sam ob容kt, u nego vyzyvaetsya metod index_html.
Sozdadim malen'kij sajt. V koren' pomestim DTML Method index_html
prostogo soderzhaniya:
<dtml-var standard_html_header>
<dtml-var content>
<dtml-var standard_html_footer>
i DTML Document content, hranyashchij sobstvenno soderzhanie razdela, voobshche bez
zagolovka/podvala.
/
standard_html_header
standard_html_footer
index_html
content
Razdel1
content
Razdel2
content
Obratimsya k kornyu sajta: http://www.server/. Kornevaya papka vyzovet svoj
index_html, kotoryj interpretiruetsya, podgruzit sootvetstvuyushchie zagolovok i
podval. Nichego osobennogo.
Teper' obratimsya k odnomu iz razdelov: http://www.server/Razdel1/ |tot
papka, poetomu ona vyzovet svoj index_html... No v Razdel1 net svoego
index_html. On zaimstvuetsya iz kornya! Nu, i poskol'ku on DTML Method, to on
sam zaimstvuet atributy iz dinamicheskogo konteksta. Header/footer voz'mutsya
iz kornya, a content iz Razdel1.
Tretij, i poslednij primer sovsem kratko. V papke db lezhat dtml-metody
(pust' dtml-metody budut nazyvat'sya db/view, db/insert, db/update), i
sql-metody, kotorye parametrizovany (imya tablicy, imena stolbcov).
Dalee, vnutri etoj papki delaetsya papka, naprimer users. V ee atributy
propisyvayutsya konkretnye parametry dlya metodov (imya tablicy, imena
stolbcov).
Po obrashcheniyu db/users/view - poluchaem gotovuyu stranichku s soderzhimym
tablicy. Metod view (ravno kak i insert i update) unasledovan iz db, no
zaimstvuet atributy iz users.
Metod db/users/insert (unasledovannyj iz db) prochtet iz svojstv papki
db/users nazvanie tablicy, nazvaniya polej, i skonstruiruet formu, dlya
dobavleniya zapisi. To zhe budet proishodit' s drugimi papkami, i ih
svojstvami. V hode razvitiya proekta, tochno tak-zhe kak i dlya sluchaya OO
programmirovaniya, dobavlenie novyh metodov v "bazovyj ob容kt" db (naprimer
nuzhno budet sdelat' poisk - db/search) avtomaticheski rasshirit
funkcional'nost' "potomkov" db/users, db/something...
SECURITY - mehanizmy bezopasnosti v Zope
--------
Zope predostavlyaet programmistam i administratoram prostye, i v to zhe
vremya moshchnye i gibkie mehanizmy upravleniya bezopasnost'yu. Bezopasnost' v
Zope stoit na treh kitah, treh bazovyh ponyatiyah - pol'zovatel', rol', i vid
dostupa.
Vid, ili tip dostupa opredelyaet programmist pri sozdanii komponenta.
Kazhdomu klassu v komponente opredelyaetsya polnomochie "Add" ("Dobavit'
ekzemplyar klassa v derevo ob容ktov"), kazhdomu metodu klassa mozhno
opredelit' svoi sobstvennye polnomochiya, kotorye opredelyat, komu i kakoj vid
dostupa predostavlen k etomu metodu klassa. Naprimer, metodu index_html
(kotoryj vyzyvaetsya pri obrashchenii k ob容ktu, a ne k konkretnomu metodu)
obychno daetsya vid dostupa View. No eto delo programmista, kak nazvat' svoi
polnomochiya, i kakie metody kakimi polnomochiyami zashchitit'. Obychno metody
ob容kta ob容dinyayutsya v gruppy, predostavlyayushchie odin servis. Naprimer, klass
NovostevayaLenta mozhet imet' servisy (gruppy metodov) "pokaz novostej",
"dobavlenie novostej", "redaktirovanie novostej", "udalenie novostej",
"dobavlenie/redaktirovanie/udalenie rubrik". I kazhdyj iz servisov mozhno
zashchitit' (dav emu otdel'nyj vid dostupa) - s tochnost'yu do odnogo metoda.
Dlya bolee tonkogo upravleniya, uzhe vnutri metoda, programmist mozhet
zaprosit' SecurityManager - "imeet li tekushchij pol'zovatel' prava na
sozdanie DTML Metodov v Papke Razdel?"
Roli sozdaet administrator sajta cherez menedzherskij web-interfejs Zope.
Ponyatie roli rasprostranyaetsya ne na ves' sajt, ne na ZODB, a na chast'
dereva. Administrator sozdaet rol' v kakoj-to papke, i dal'she blagodarya
mehanizmu acquisition eta rol' rasprostranyaetsya vniz po podderevu.
Zope, postavlennaya iz distributiva, imeet 3 roli, opredelennye v korne
ZODB - Anonymous, Owner i Manager. Manager - eto takoj vsesil'nyj
administrator, analog ruta. Owner - vladelec teh resursov, kotorye on
sozdal. Anonimnyj pol'zovatel' - prosto posetitel' sajta; emu iznachal'no
dostupny tipy dostupa: Access content, View, Use SQL Methods (eto dlya togo,
chtoby pozvolit' vyzyvat' SQL Metody iz DTML Metodov) i Search ZCatalog.
Administrator sajta v dal'nejshem mozhet sozdavat' novye roli, kak v korne,
esli u samogo administratora est' prava na redaktirovanie kornya, tak i v
lyubyh podderev'yah, na kotorye u administratora est' prava.
|ti 2 mehanizma - kategorii dostupa i roli - sovershenno ortogonal'ny, i
v web-interfejse obrazuyut tablichku iz soten checkbox'ov - kakoj roli kakie
kategorii dostupa.
Administrator sajta mozhet, naprimer, zavesti roli Editor i ChiefEditor,
i dat' roli Editor prava na redaktirovanie DTML Document'ov, a roli
ChiefEditor - prava na redaktirovanie DTML Method'ov, kartinok, i na
sozdanie papok. Dav roli SubAdmin prava na administrirovanie bezopasnosti v
poddereve sajta, administrator effektivno delegiruet polnomochiya.
Pol'zovateli (to est' zapisi o pol'zovatelyah) - eto ob容kty (kak i vse
ostal'noe), ekzemplyary klassa User. Iznachal'no Zope stavitsya s komponentom
UserFolder, kotoryj hranit eti ob容kty v ZODB, i mozhet poluchat' i proveryat'
username/parol' tol'ko po sheme Basic Authentication. No komponentnaya
tehnologiya i zdes' daet svoi preimushchestva. Uzhe dostupny komponenty:
-- etcUserFolder, kotoryj beret dannye iz fajla; format fajla ugadajte
sami :)
-- UserDB - hranit zapisi o pol'zovatelyah v SQL; hodit za nimi v SQL ne
sam, a pol'zuetsya standartnym sloem abstrakcii ZSQL, tak chto mozhet
stavit'sya na lyuboj SQL-server (k kotoromu u Zope est' adapter)
-- RadiusUser, MysqlDB, NTUserFolder, NISUserFolder - nu, pro etih vse
ochevidno
-- GenericUserFolder - pozvolyaet programmistu samom pisat' procedury
autentifikacii
-- LoginManager, Membership - bolee prodvinutye, no menee otlazhennye
varianty GUF; chasti Zope Portal Toolkit
Vse perechislennye komponenty umeyut kak Basic Auth, tak i kuki. Na sajte
mozhno rasstavit' skol'ko ugodno ekzemplyarov raznyh komponent, i takim
obrazom avtorizovyvat' odnu chast' sajta iz domena NT, a druguyu - iz SQL.
K sozhaleniyu, postavit' v odnu papku 2 raznyh UserFolder nel'zya.
Tip dostupa dlya pol'zovatelya proveryaetsya ne neposredstvenno, a cherez
roli. Zapis' o pol'zovatele (ob容kt klassa User), pomimo logina i parolya,
hranit spisok ego rolej, i spisok domenov i/ili IP, s kotoryh pol'zovatelyu
razresheno rabotat'.
Opyat'-taki, blagodarya mehanizmu zaimstvovaniya, zapis' pol'zovatelya
dostupna i proveryaetsya vezde v poddereve, na vershine kotorogo eta zapis'
vnesena.
Eshche odin mehanizm nuzhen, esli kakoe-to privilegirovannoe dejstvie nado
pozvolit' sovershit' pol'zovatelyu, ne obladayushchemu nuzhnymi privilegiyami.
Skazhem, dat' na prosmotr (no tol'ko na prosmotr) Dokument, dostupnyj tol'ko
Menedzheru. Togda eto konkretnoe dejstvie opisyvaetsya (skazhem, na DTML
pishetsya Metod dlya prosmotra), i etomu Metodu daetsya Proxy Role pod rol'
Manager. Polnyj analog yuniksovogo setuid, i kak so vsyakim setuid, nado byt'
ochen' vnimatel'nym, chtoby ne nasozdavat' dyr v zashchite.
Nakonec, poslednij mehanizm, Local Role, pozvolyaet dat' opredelennomu
pol'zovatelyu dopolnitel'nye prava (roli) na konkretnyj ob容kt. Tak-to roli
dayutsya pol'zovatelyu tam, gde opredelena zapis' pol'zovatelya; Local Role
pozvolyaet opredelit' dopolnitel'nye roli v kontekste ob容kta, a ne
pol'zovatel'skoj zapisi. Lokal'nye roli ne zaimstvuyutsya mehanizmom
acquisition.
----------
-- otsutstvie horoshej dokumentacii i literatury
-- nedostatochnaya podderzhka lokalej: sortirovka v cikle dtml-in
osushchestvlyaetsya sovershenno bez ucheta lokali, indeksaciya i poisk v
Catalog trebuet komponenta Splitter (yaponcy napisali sebe JSplitter,
mezhdu prochim, a my pol'zuemsya amerikanskim)
-- tyazhelo otlazhivat' pitonovskie komponenty - Zope nado perezapuskat',
chtoby on podhvatil izmeneniya v kode, a eto neudobno i dolgo (sekund
20-30); Z-klassy ne imeyut takogo ogranicheniya, no i vozmozhnostej u nih
pomen'she
Nedostatki Zope v osnovnom yavlyayutsya prodolzheniem dostoinstv etoj
platformy.
-- server, vse vremya sidit v pamyati
-- otsutstvie vozmozhnosti derzhat' istoriyu ob容ktov v CVS
-- yazyk programmirovaniya - Piton; dlya programmirovaniya obeshchano
dobavlenie PerlMethods i mozhet byt' drugih yazykov
-- sam napisan na Pitone, u kotorogo est' svoi sobstvennye nedostatki.
Naprimer, global'nyj lock dlya vseh nitej. |to znachit, chto Piton (i
sootvetstvenno Zope) ne smogut izvlech' vse preimushchestva
mnogoprocessornoj mashiny
Nekotorye osobennosti imeyut otdel'nye komponenty Zope.
-- ne rekomenduetsya hranit' mnogo ob容ktov v odnoj papke - poisk
osushchestvlyaetsya linejno; variant BTreeFolder poka v stadii otladki
-- Versii realizovany otlozhennymi tranzakciyami; v rezul'tate ob容kt,
redaktiruemyj v Versii, zapiraetsya v nej, i ego nel'zya redaktirovat'
ni vne Versii, ni tem bolee v drugoj Versii
RUSSKOYAZYCHNAYA GRUPPA POLXZOVATELEJ Python i Zope
----------------------------------
U nas eshche net svoego sajta, on v processe sozdaniya, no gruppa otlichaetsya
aktivnost'yu i interesom k prodvizheniyu tehnologii Zope. Vy mozhete
podpisat'sya na nash spisok rassylki, poslav pis'mo s telom (s telom, ne s
temoj) subscribe python po adresu majordomo@list.glasnet.ru. Administrator
spiska - Evgenij Dvurechenskij http://www.glasnet.ru/~jno/; hosting spiska -
Rossiya-On-Lajn.
Oleg. (All opinions are mine and not of my employer)
----
Oleg Broytmann National Research Surgery Centre http://sun.med.ru/~phd/
Programmers don't die, they just GOSUB without RETURN.
Last-modified: Mon, 03 Jul 2000 11:18:16 GMT