Názory k článku Aplikační server Zope
-
hugo (neregistrovaný)
Ja mam velmi lehke znalosti tohoto weboveho serveru (cca jsem v nem pracoval asi mesic) a ze bych na nej pel slavu, to rozhodne ne.
Nevynikal zadnou velkou rychlosti, prace s sql byla znacne nekomfortni - zmena db session znamenala nutnost rucni kompilace vsech sql dotazu (jinak nefungovaly) atd.
Muj pocit na zacatku prace byl - uzasne, supr, jak to, ze jsem to neznal driv a po mesici jsem byl presvecen, ze nikdy vice (a musim priznat, ze od te doby ani pythonu nemohu prijit na jmeno).
Ale moje zkusenosti jsou vice nez rok stare a treba je Zope ted uz uplne nekde jinde nez bylo pred rokem. -
Michal Benes (neregistrovaný)
Ja mam zkusenosti s Zope 2.5. Tezko srovnavat, ostatni reseni neznam, Zope mi prijde jako velmi pekny projekt, ale privital bych, kdyby nebylo webove rozhrani preferovanym zpusobem ovladani - obcas jsem si take dost nechutne zaklikal :-( A to nemluvim o editaci zdrojaku. Proste bych privital, kdyby vse bylo pekne v adresarove strukture na disku a ne v ZopeDB (uz proto, ze by se daly delat symlinky).
Obcas me Zope dost vytacel, ale stejne ho doporucuji k vyzkouseni. A jestli se vam nebude libit, nezavrhujte kvuli nemu Python, ktery je ted asi muj nejoblibenejsi jazyk :-) -
David (neregistrovaný)
Je pravda, ze "standardni" instalace Zope asi z pohledu zacinajiciho uzivatele "trpi" temito nedostatky, ale to neznamena, ze to je zaroven hranice moznosti systemu.
Jak uz bylo receno, zdrojaky jde editovat i vzdalene pres FTP, WebDAV, HTTP PUT, nebo i jinymi zpusoby diky Zope Productum (external editor, napriklad). Data na disk (misto do ZODB) se daji take ukladat primo, pokud si stahnete Product filesystem storage, nebo tak nejak (najdete to v download sekci Zope mezi Producty External Access). A k samotnemu ovladani staci snad jen rici, ze cely 'manage' interface je sam napsan v Zope a v ZopeBook je dokumentovano kompletni API, takze neni problem si udelat
a) vlastni WWW rozhrani pro caste akce
b) vlastni Python scripty, kterymi pak muzete ovladat Zope v podstate odkudkoliv, treba si k tomu napsat i vlastni okenni rozhranni, napriklad ve wxPythonu (i kdyz to je asi spis pro hardcore vyvojare)
K jinde zminovane rychlosti se da rici asi toto: Zope neni nejrychlejsi. Samotne ZPT jsou spise "pomale" nez "rychle". DTML je na tom dle mych zkusenosti o trochu lepe. Navic DTML neni "nadstavbou" HTML. Je to samostatny jazyk urceny hlavne pro vystup do dokumentu (a tim vystupnim formatem nemusi byt nutne HTML, ale treba i PDF, ci jakykoli jiny strukturovany jazyk/text). Oproti tomu zminovane ZPT jsou urceny hlavne pro vystup do HTML (a jejich syntaxe je vazne pekna - vse se pise jako atribut tagu, takze ani kdyz to nekdo prozene pres FrontPage, tak vam nerozsype kod uvnitr. Sami autori pisi, ze ZPT jsou tu hlavne proto, aby vyvojar mohl dat bez obav takovou sablonu designerovi a ten s ni nic "neprovedl").
Musim se ale sam priznat, ze poprve jsem se se Zope setkal ve verzi 2.2.2, kdy me velice zaujal, ale nebyl jsem schopen se ho poradne naucit a nyni s verzi 2.5.x se k nemu zase pomalu vracim a chci se do toho poradne "oprit". -
hugo (neregistrovaný)
Mel jsem na mysli rychlost serveru - pokud jsme ho testovali pro standardni provoz, tak ve srovnani s php+apache byl velmi dychavicny.
A stran SQL - jednalo se o pripojeni k Oracle - jakmile jsem zmenil databazi, musel jsem vsechny sql dotazy znovu projit a zkompilovat (tj. zmacknout tlacitko Change), jinak server pri vyvolani prikazu vyhodil chybu. Pokud jsem tam mel asi 100 dotazu, tak preklapeni z testovaci db na ostrou bylo velmi nezazivne. -
Stoki (neregistrovaný)
Existuje nieco ako VisualWave pre visual works,
ale nerobil som s tym nejak blizsie. S cim som robil je
Swiki Web server bezi to pod Squeakom, celkom dobry wev-serverik
s mnozstvom uzitocnych veci ako udrziavanie konzistenicii liniek,
editovanie a pod... http://minnow.cc.gatech.edu/swiki -
subzero (neregistrovaný)
Ano jak VisualWave, tak komponenty ClassicBlend umoznuji tvorbu web aplikaci ve Smalltalku/VisualWorks. Drobny problem je ale s implementaci lokalizace a interpretaci prvku UI, ktere nemaji v HTML ekvivalent. Visual Wave je zobrazi jako obrazek, ClassicBlend se snazi vygenerovat aplet (s kolisavou uspesnosti). Touhle tecnologii je delan napr. fractal.cz.
-
Jirka Stepan (neregistrovaný)
Nad Zope (resp. jeho starsi verzi) jsme vyvijeli pres rok a pul. Na prvni pohled se jedna o super vec, ale je tu spousta drobnych problemu:
- vykon a stabilita - system kyne v pameti. Velikost objektove databaze narusta. Existuje ta uzke hrdlo pri komunikaci mezi webserverem a samotnym Zope procesem.
- spatna prace se sessions. V Zope 2.5.1 uz neco takoveho existuje ale je to divne prilepene.
- v posledni dobe vyrazne zpomaleni cinnosti prilehle komunity.
- problemy s vyvojem a deployingem aplikaci. Nelze integrovat s oblibenym vyvojarskym nastrojem, editace na webu je pekna ale po case omrzi. Vpodstate nulova moznost debugovani.
- problemy s know how a tymy. Dokumentace existuje k jadru. jednotlive produkty jsou jiz dokumentovany mene. Navic cloveka ktery umi napr. javu sezenete do tymu z tyden. Clovek ktery umi zope je spise vyjimkou.
Zaver: je to pekne pro ne uplne vazne myslene projekty s mensi aplikacni logikou. Jinak doporucuji tu javu :-) -
Jiri Hnilicka (neregistrovaný)
ano.. s timto nazorem nemuzu nez souhlasit a docela me zaujal nazor v clanku, ze pomalost javy vyresil autor prechodem k zope. nemyslim si, ze si tim nejak prilepsil.
vzhledem k tomu, ze jsem zkousel obe technologie (byl jsem pred podobnym problemem - potreba udelat stredne velky projekt rychle), tak me Zope docela zklamalo a zustal jsem radeji u Javy. Melo na to vliv i to, ze v jave jsem delal uz driv (ne weby), ale o pythonu jsem nemel tucha. A nemam rad, kdyz me nekdo da jenom nejaky makrojazyk a dovnitr me nepusti (protoze bych tomu jazyku nerozumnel).
Java ma dnes vetsi podporu, zna ji mnoho vyvojaru a ta rychlost vazne neni spatna. Rekneme od Celerona 350 (a to je dnes na server opravdu chuda konfigurace) uz rychlost neni hlavni problem. A to nemluvim o J2EE, se kterou jsem v posledni dobe zacal delat + JSP. Kam se Zope hrabe! -
dm (neregistrovaný)
Delame v Zope nekolik projektu jiz nejakou dobu a je to velmi pekny system. Jelikoz mame zkusenost i s jinymi systemy (PHP, Lotus Notes) muzeme porovnavat.
Nutno rici, ze kazdy system ma mouchy, at komercni nebo otevreny. Alternativne delame v Lotus Notes a staci se podivat do diskuse na lotusu, kolik problemu musi programatori resit. A to je v diskusich ke kazdemu systemu. Obecne plati, ze pokud bych se podival do diskuse k nejakemu systemu, tak bych jej asi jiz nepouzival, nebot je to hodne o chybach a nedostatci. A to tyka jak ZOPE tak PHP, JAVA atp. -
ViNiL (neregistrovaný)
Při čtení tohoto flameu jen trochu lituji, že místo psaní "ostrých proseb" se raději něvěnujete čtení patřičných dokumentů. Nemíním tu rozebírat, že omezení na ZMI (ta webová interface) nebo ZODB (ta interní objektová databáze) je naprostá blbost. Kdyby Vás to zajímalo, tak si rovnou ušetříte podobné výstupy.
Zope není ani tak nějaké konkrétní, technické řešení, jako spíš filosofie přístupu k informačním systémům. Bavit se o jeho konkrétních možnostech a nedostatcích je dosti ošidné, protože aplikací nějakého modulu se poměry mohou třeba i obrátit. U Linuxového kernelu také neříkáme, že umí pouzet pět filesystémů, že?
Jediná praktická výtka, co tu padla, se týkala rychlosti. Rychlost Zopeu je z podstaty věci závislá na rychlosti Pythonu. Ten má nějaké minimum, do kterého ještě poznáte, že se jedná o byte-kód a od něho výš už je to v pohodě. Dnešní počítače jsou rozhodně vysoko v druhé kategorii. Samozřejmě, pokud provozujete na 386-ce Apache, tak bude podávat daleko lepší výkon, než Zope, ale o tom to asi není.
Další rychlostní problém nastává v obsahu Zopeu. Jak tu bylo již řečeno, nejhůř jsou na tom asi ZPT. DTML je několikrát rychlejší a Pythonovské skripty nebo externí metody běží (s malinkatým overheadem) svou nativní rychlostí. Takže naopak, máte možnost si vybrat podle svých potřeb: čím vyšší "jazyk", tím snadnější a rychlejší pořízení kódu, ale pomalejší běh. Na možnosti volby nespatřuji nic špatného.
To už ani nemluvím, že máte možnost časově kritické metody všelijak cacheovat apod.
Souhrnem, Zope je jeden z nejkomplexnějších a nejflexibilnějších systémů, se kterými jsem se setkal. Naprostá většina "bugů" zde zmíněných a těch, které vás napadnou bez hlubší znalosti věci, je výsledek neznalosti, či nepochopení. Ne, že by Zope neměl chyby, ale nejprve se s ním trochu seznamte -- jde to velmi snadno. -
Cohen (neregistrovaný)
To je nesmysl, ty prispevky a i clanek jsou o praktickem pouziti Zope. Interni implementace je zalezitost jina. Pokud neni na nektere veci dostatecne rychly, tak neni a vetsinu vyvojaru webovych aplikaci vicemene nebude zajimat proc, pokud s tim nelze snadno neco udelat (napr. nastavenim). Zope jiste je jednim z nejkomplexnejsich systemu, ale ve vysledku mi prijde trosku roztristeny. Ostatne i vyvojari Zope si na jeho implementaci stezuji a ve verzi 3.0 ma byt velka cast systemu prepsana, protoze je obtizne psat moduly.
Chvala proc ne, ale odsud az potud. Ryze pozitivni prispevek si rika o kritiku ;-) -
hello_world.stx (neregistrovaný)
neodpustím si flák citátu lao-c': "...cesta povolaného je působit bez zápolení".
nechápu, proč se absolutně každé diskusní fórum (ať už je o politice či erotice) okamžitě zvrhne na "diskusi" typu: "co je to za kravinu? vždyť TOHLE je úplný shit! ale TODLE, to je skutečně super! a jestli se mnou nesouhlasite, jste čuráci!" chcete se dozvědět něco O PROBLEMATICE? nečtěte diskuse!
ale proč píšu. cituji "Zope není ani tak nějaké konkrétní, technické řešení, jako spíš filosofie přístupu k informačním systémům." tak to bych si vytiskl a pověsil někam pod lao-c'. :) jinak by to v "diskusi" úplně zaniklo a to by byla škoda.
jinak off-topic! -
SysOp (neregistrovaný)
Ja mam ze Zopem cca rocni zkusenost a nemuzu rict, ze by byla dobra. Jak uz to nekdo zminil, jednim z problemu je rychlost. Ve srovnani s PHP je Zope podstatne pomalejsi a pristup do SQL databaze (konkretne Firebird) je skoro nocni mura - radove pomalejsi nez treba u PHP a celkem casto to pada. Editace v HTML formulari vypada ze zacatku jako vyborny napad, ale pro seriozni praci je to skoro nepouzitelne - napr. se v tech zdrojacich neda grepovat :-)))
Neznam prilis ZPT, ale DTML vubec neresi oddeleni vzhledu a funkcnosti, naopak je podle meho nazoru micha dohromady. V PHP (s C like syntaxi) alespon na prvni pohled poznam, co je PHP a co je HTML, syntaxe DTML je velmi podobna HTML a rozlisit (navic jeste v editacnim formulari) co je co je velmi obtizne. Kdyz chci na chvilku neco zakomentovat, musim napsat <dtml-comment>neco</dtml-comment>. Zlaty PHPko a #.
To ze se u dokumentu nepouzivaji pripony muze taky obcas vadit. Napr. kdyz jsme chteli udelat sloziteji staticky web a ty staticke stranky vynenerovat wgetem ze Zopu, vyzadovalo to pak jeste spoustu hrani s sed. Krome toho kdyz si takovou stranku ulozim, tak ji pak musim prejmenovat, abych ji kliknutim otevrel.
Ze pri pouzivani sessions se pri neuspesnem loginu vraci 500 Internal server error nebo ze neni spravne implementovay HEAD jsou pak uz jen tresnicky na dortu.
Samotny python jsem si naopak docela oblibil, pokud mi na neco nestaci bash, automaticky sahnu po pythonu. Chvili sice trva, nez si clovek zvykne na odsazovani misto zavorek, ale kdyz to ma pak po case clovek po sobe (nebo nedej boze po nekom jinem) cist, je to k nezaplaceni. -
O. Auda (neregistrovaný)
ZOPE sice není dokonalý nástroj (takový neexistuje), ale převažující kritika v této diskuzi svědčí spíše o kriticích a jejich neznalosti ZOPE než o ZOPE. Poznámka "že by analfabeti" je poměrně trefná.
ZOPE je spíše prostředí než jazyk. Nemusíte použít ani ZPT ani DTML ani Python a využívat ZOPE - např. pro XML a TeX. Nemusíte použít vůbec webové rozhraní (ZMI), transakční objektovou databázi (ZODB).
ZOPE lze používat s různou úrovní znalostí (to byl cíl). Mnoho komentářů prozrazuje nízkou úroveň pochopení konceptů použitých v ZOPE, což by bylo neutrální, kdyby to nebylo použito jako přesvědčivé konstatování o nevhodnosti ZOPE.
Hlavní nevýhodou ZOPE je pravděpodobně obtížnost učení. Některé koncepty jsou prostě hůře pochopitelné. Investice do získání hlubších znalosti ZOPE se vrátí až při větších projektech.
ZOPE není rychlý, ale je rychlý dostatečně. Existují postupy, které významně urychlují renderování výsledku - správné rozdělení do objektů, využití cache, DTML objekty nejsou vhodné pro programování funkcionality, údržba databáze atp. Imho rychlost není problém ZOPE.
Ani stabilita, relační databáze, editace v browseru, skrytost objektů v ZODB aj. nejsou skutečné problémy ZOPE.
ZOPE nelze srovnávat s PHP (ASP), je to jiná váhová kategorie.
Při srovnání s ostatními aplikačními servery má každý z nich své výhody a nevýhody. Je na individuálním rozhodnutí (ať už na úrovni firmy, ať už na úrovni projektu), který bude vhodnější. ZOPE je plnohodnotným řešením i pro velmi rozsáhlé projekty. Pokud uvažujete o volbě platformy a zvažujete i ZOPE, s důvěrou se na nás obraťte, rádi vám pomůžeme.
O. Auda, auda@aow.cz, http://www.aow.cz/ -
dan (neregistrovaný)
hehe, koukl jsem na ten vas komercni sajt, jestli opravdu bezi na zope - a fakt jo, ale behem kratke chvile jsem nasel nekolik chyb vyuzitelnych pro utok na ten system. takovyto www editor zrovna nepotrebuji :|
btw ad mod_perl, nedavno bylo v embperl konfery srovnani rychlosti, nedopadlo moc dobre :( -
O. Auda (neregistrovaný)
Autor píše "Pomocí technologie DTML a ZPT budete skutečně psát celou aplikaci, aniž byste napsali řádek v Pythonu."
Je to možné, ale nedoporučuje se to.
DTML (ZPT) jsou šablony - jsou nositeli designu. Funkcionalita zde naprogramovaná je (pro jiný než malý rozsah) nepřehledná a pomalá. Podle mého názoru je to důvod většiny nářků na pomalost ZOPE.
Není důvod se bát Pythonu. Nemusíte ho znát dokonale. Je jednoduchý, velmi rychlý na naučení a velmi přehledný.
Před několika lety bylo na zope irc kanálu hitem odrazovat od psaní funkcionality v DTML. Myslím, že oprávněně. -
bob (neregistrovaný)
No musim zareagovat, a zastat sa Perlu a HTML::Mason.
Oba su to perfektne nastroje a Mason je velmi vhodny na vytvaranie web aplikacii. Treba si vsak uvedomit, ze Mason je "len" nastroj. Avsak vyhodou Perlu je, ze podporuje velke mnozstvo takychto nastrojov (CPAN).
Mason sam o sebe napriklad nepodporuje sessions, ale nie je ziaden problem pouzit Apache::Session, pripadne iny modul.
Pokial ide o vykon, pre bezne aplikacie je uplne bezproblemovy, a v kazdom pripade sa da bez problemov porovnavat (t.j. je porovnatelne vykonny, prip. vykonnejsie) s ostatnymi rieseniami.
ČLÁNKY DO MAILU