Zope, Plone - ako to dopadlo

20.12.2006 00:52 | Přečteno: 1326× | poslední úprava: 20.12.2006 00:53

Pred casom som pisal zapis, v ktorom som nadhodil zopar otazok ohladom Zope/Plone a ich pouzitelnosti na intranetove CMS, ktore by malo umoznit aj tvorbu databaz (resp. databazovych rozhrani). Na uvod tohto zapisu by som sa chcel podakovat vsetkym, ktori prispeli do diskusie. A ako moje rozhodovanie dopadlo?

Aplikacia, ktoru si kladiem za ciel svojho snazenia, sa da strucne popisat asi nasledovnym sposobom: intranetove CMSko, ktore by v principe fungovalo z pohladu pouzivatela podobnym sposobom ako klasicky filesystem, s tym, ze okrem "objektov" typu "subor" a "adresar", bude poskytovat napriklad typ "clanok", "diskusia", ale aj zlozitejsie moduly (vytvorene objekty volajme "nody"), ako napr. rozne databazy pre evidenciu neviem coho. Z tychto nodov si uzivatel bude moct vystavat, pouzitim weboveho rozhrania, strukturu webu, aka sa mu len zachce. Priklad: zacne od nejakeho "root nodu", ktory bude povedzme defaultnou strankou, pod nim si vytvori node typu "adresar" pod nazvom "Dokumenty", pod nim dalsi, povedzme "Vseobecne", kde si bude vytvarat zasa co sa mu zachce. Z tejto struktury sa bude automaticky generovat menu atd. Pristupove prava - opat podobne ako to uz uzivatel pozna, subor bude mat "download", "update", clanok zasa "view", "edit", pricom tieto prava bude mozne pridelovat podla lubovole a hlavne "per node", teda nie globalne pre urcity typ nodu, ale pre kazdy konkretny node.

Aby som bol presny, takuto aplikaciu (ci skor prototyp) som uz zbuchal v PHP, za pouzitia nejakych externych veci, ako napriklad templating engine a podobne. Je to funkcne, zatial to robi co potrebujem. Je to dobre ako "proof of concept", ale ako ostru aplikaciu by som to neoznacil. Z pohladu pouzivatela funkcne, z pohladu programatorskeho pomerne neciste. Ako priklad uvediem pracu s SQL databazou - v kazdom "module" je potrebne vytvorit CRUD funkcie. Okrem toho nakodovat prijimanie a validaciu dat od uzivatela, pritom by sa to pre typicke pripady vyriesit zadefinovanim jednotlivych datovych poloziek. Priklad: poviem, objekt typu "clanok" sa bude skladat z tychto casti:

• nadpis, to je text, max 50 znakov, povinne
• datum vydania, to musi vyzerat ako datum, povinne
• telo clanku, text, povinne
• ...

Z toho mi nieco vygeneruje vstupny formular, spravi validaciu, CRUD,...

Presne tymto sposobom to robi Plone a velmi sa mi to paci, okrem toho ponuka aj nejake dalsie vymozenosti, ako napriklad workflows. Uplne idealne na tvorbu typickych webov. Problemom su vsak prave spominane "zlozitejsie nody", napriklad aplikacia typu "databaza elektronickych suciastok". Som zvyknuty riesit tieto veci cez relacne databazy, avsak Plone pouziva objektovu ZODB, na com nie je nic zle (vo vacsine pripadov skor naopak), avsak nepodarilo sa mi najst vela informacii o tom, ako ziskat vsetky agregacne funkcie (resp. nieco ekvivalentne), ktore pouzivam v relacnych databazach. Existuju sice moznosti, ako ho prinutit ukladat data napriklad do PgSQL, ale ten sposob mi prisiel ako nie celkom cisty (zrejme len moj osobny problem, ale co uz). Vo vysledku by boli nejake data v ZODB, nejake v xSQL, co mi nepride ako idealne.

Takze zaver (moj osobny nazor): ak hladate nieco na web a zaobidete sa bez SQL, kludne sa dajte do studia Zope/Plone, podla mna sa to vyplati, ma to vela krasnych vlastnosti, ktore vam velmi ulahcia zivot. Ak ste vsak relacny typ :), zrejme narazite na veci, ktore tak lahko neprekusnete.

Kam povedie dalsie patranie? Bude o tom nasledujuci zapis, nedockavcom prezradim, ze uz nejaky ten tyzden sledujem stopy javovskeho Strutsu. Aby nedoslo k omylu, dvojica Zope/Plone sa da so Strutsom len tazko porovnavat, to prve je framework s vlastnou objektovou databazou+hotove CMS s rozhranim pre tvorbu vlastnych "typov nodov" a vela dalsieho, zatialco Struts je "len" MVC framework. Zda sa mi vsak, ze pre moje ucely bude vhodnejsi prave dobry MVC framework, na ktorom si tu aplikaciu postavim sam, sposobom aky mi vyhovuje.

Poznamka: ked toto pisem, som uz zrely do postele, budem si to musiet este po sebe precitat, ci som nezamiesil na nejaky flame, resp. nenapisal tam z nepozornosti nejaku hlupost. Rovnako sa mohlo stat, ze som tam napisal nejaku hlupost z nevedomosti. V kazdom pripade budem rad, ak ma na to v diskusii upozornite.        

Komentáře

[Honza Král]

Ja bych vrele doporucil django, umoznuje:

nadefinovat jednoduse objekty

vytvori SQL tabulky a spol (PostgreSQL/MySQL/SQLite...)

ma automaticke admin rozhrani (pro zadavani udaju)

spravu uzivatelu (vcetne prav, ktere jsou pouzity v adminu a daji se pouzit i v custom kodu)

generovani formularu i celych akci (generic views) - napriklad pridani/uprava nebo vymazani objektu, detail a list objektu, archiv...

ma prijemny ORM a umoznuje fallback do SQL

aktivne se vyviji a je pod BSD licenci... to cele navic v pythonu, co vic si prat? ;)

[hab]

dakujem, urcite sa na to pozriem

[Daniel Kvasnička ml.]

No, ja bych jen pro objektivitu doplnil, ze admin rozhrani je pro opravdu standartni situace -- nekdy clovek potrebuje v adminovi takovou funkcionalitu, ze hackovat generovane rozhrani je zdlouhavejsi nez to napsat. To mi radili i lide z Django-users na Google Groups A napsat si relativne univerzalne pouzitelne CRUD metody neni problem.

Me se velice osvedcil TurboGears, ktery admin negeneruje, ale ma perfektni spravu identit, XML sablony a jede na CherryPy, coz je mi blizke. Pravda je, ze v Djangu se ten templatovaci paskvil da take jednoduse nahradit Kidem ci necim jinym.

Nicmene Django je spicka a na mnoho scenaru bych ho samozrejme nevahal pouzit.

Btw: vypada to nejak realne s nejakym slusnym ceskym hostingem zamerenym na tyto frameworky?

[Honza Král]

No, ja bych jen pro objektivitu doplnil, ze admin rozhrani je pro opravdu standartni situace -- nekdy clovek potrebuje v adminovi takovou funkcionalitu, ze hackovat generovane rozhrani je zdlouhavejsi nez to napsat.

naprosty souhlas, admin je neco, co clovek pouziva u blgu ci cms k zadavani dat, ne co ukazuje uzivatelum...

To mi radili i lide z Django-users na Google Groups A napsat si relativne univerzalne pouzitelne CRUD metody neni problem.

ale hlavne to neni nutne - na skutezne zakladni veci (CRUD) existuji ty generic view, u kterych staci jen dodat HTML, pripadne napsat jednoduchyy wrapper, ktery naplni/schova nejake fieldy atd...

jinak se samozrejme hodi poznamka, ze django ma skvelou komunitu (muj fanatismus je toho jiste prikladem ;) )

Btw: vypada to nejak realne s nejakym slusnym ceskym hostingem zamerenym na tyto frameworky?

premyslim o tom, zatim resim nejake problemy spojene s behem pythonu v zabezpecenem prostredi... urcite dam kdyztak zpravicku, nebo minimalne poslu mail do skupiny (existuje i ceska, i kdyz ponekud neaktivni)

[Daniel Kvasnička ml.]

ale hlavne to neni nutne - na skutezne zakladni veci (CRUD) existuji ty generic view, u kterych staci jen dodat HTML, pripadne napsat jednoduchyy wrapper, ktery naplni/schova nejake fieldy atd...

Ja jsem si je v TurboGears napsal, i kdyz myslim, ze tam neco na zpusob generic views taky je.

premyslim o tom, zatim resim nejake problemy spojene s behem pythonu v zabezpecenem prostredi... urcite dam kdyztak zpravicku, nebo minimalne poslu mail do skupiny (existuje i ceska, i kdyz ponekud neaktivni)

No kdyz ty apps nebudou primo v adresari kam ma Apache pristup, tak by to nemel byt problem zabezpecit, ne?

Kazdopadne ten hosting by sednul. Inspiraci bych videl ve WebFaction -- videl jsem ty jejich screencasty a je to hukot

[Honza Král]

premyslim o tom, zatim resim nejake problemy spojene s behem pythonu v zabezpecenem prostredi... urcite dam kdyztak zpravicku, nebo minimalne poslu mail do skupiny (existuje i ceska, i kdyz ponekud neaktivni)

No kdyz ty apps nebudou primo v adresari kam ma Apache pristup, tak by to nemel byt problem zabezpecit, ne?

me slo spise o zabezpeceni serveru proti klientum - aby si kazda aplikace nemohl spoustet jakekoliv prikazy pythonu atd... navic nevim jestli by slo udelat, aby kazda aplikace bezela pod jinym userem (aby si prave navzajem nemohly skodit) a spol - to by ale mozna resilo fastcgi...

uvidime...

[Ladicek]

Pokud jde o volbu javovského MVC frameworku, tak bych neváhal doporučit Spring Web MVC Já vím, Strutsy jsou de facto standard, ale mně se ani trochu nelíbí (např. nelze mapovat formuláře na doménové objekty)… Plus spousta dalších věcí, co dostanete v jednom 2,5megovém Jaru – a jako bonus Spring Web Flow, což musí být labůžo na druhou, ale zatím s tím nemám ani nejmenší zkušenost, tak nebudu mluvit do větru.

[petr]

<span class="rejp" style="font-style:italic">Co na to Smalltalkisti, Rubysti a Lispaři?</span>

[Ladicek]

Nemůžu za to, že autor začal o Strutsech Co na to Smalltaklisti, Rubyisti, Lispaři a podobná havěť?

[Honza Jaroš]

Zajímavý je také Wicket, když už je řeč o Javě (a co se týče databází, tak samozřejmě stojí za to hodit očkem po Hibernate).

[Ladicek]

O Wicket vím, ale trochu víc se mi líbí Tapestry (jediná trošku nevýhoda je integrace se Springem, chtělo by to přeportovat ji z Hivemind na Spring ).

S Hibernate momentálně intenzivně onanuju a ta pornografie ohledně vlastnění/nevlastnění objektu danou Sessionou, nebo nedej bože rozumná implementace Open Session In View mi nedává spát

A když se to všechno dá dohromady a vezme nějaký "rozumný" programovací jazyk, vzniknou Grails

[Honza Jaroš]

Netvrdím, že je Wicket lepší nebo horší než Tapestry, to je na každém, jaký styl práce má radši. Proto jen upozorňuji, že stojí za pozornost, ale jestli ho skutečně použít nebo nepoužít, to už za ostatní neřeším, neboť mi to nepřísluší.

S vlastněním/nevlastněním objektů jsem taky bojoval, dokud jsem místo funkcí save/update nezačal používat merge. Implementaci otevírání a zavírání session v tuto chvíli řeším cachováním otevřených session v ThreadLocal, pak jen stačí před ukončením zpracování funkce service v příslušném servletu zkontrolovat, jestli není nějaká session otevřená, a případně ji zavřít.

[Ladicek]

Po pravdě, já o Tapesty ani Wicket nevím víc než jsem si přečetl, proto jsem taky použil slovo líbí. Na Tapestry se mi líbí hlavně to, že nejsou potřeba žádné extra tagy, všechno je v jednom (nebo několika málo) atributu běžných HTML tagů. I když občas to vypadá jako dost přes ruku.

Na ten merge kouknu, díky za tip.

[Martin Beránek]

ten merge vypada zajimave... na to bych se mel podivat...

jak resite lazy-bindings? ja to zatim resim otevrenou sessnou, ale neni to uplne idelani... pouzivate nekdo transport objeky bez vezeb mezi sebou?

jinak posledni dobou se mi hodne libi EJB3, tam to donuti cloveka vyresit tak nejak definitivne (stateless/stateful session beans)... dale se mi zde libi veci jako persistentni a transakcni kontext - no uz se tesim az budu mit moznost v tom neco delat

[Lukáš Zapletal]

Hezký... autor doporučujete Zope/Plone, ale handrkujete se tu úplně o něčem jiném

Plone je super, doporučuji shlédnout ten webcast o tvorbě Timetrackeru... A Zope je jediný použitelný RAD web nástroj, se kterým jsem měl tu možnost pracovat (nasadil jsem na tom inf. systémek a šlape to jak víno - zero-config :)