Názory k článku
Šablony stránek pro Zope: úvod

... JSP tags su aj tak lepsie :o) a hlavne uz je na to bohaty framework - naco programovat nieco co tu uz je a ma to bohatu komunitu programatorov?

Dle mych zkusenosti je zope celkem dobra vec na hrani, ale pro rozsahlejsi projekty doporucuji Javu - tedy, Servlety, JSP atd. Pokud chcete uz neco predpripraveneho tak napr: http://jakarta.apache.org.

ZOPE server je aplikační server v pravém slova smyslu.
Umožňuje dělat i rozsáhlé aplikace velmi rychle a to i ve srovnání z JSP, Servlety (Tomcat atp.) Kdo nezkusil ,neví o čem mluvím. A podpůrná komunita poskytující množství hotových věcí je velmi velká.

JSP tagy nejsou plnohodnotná alternativa k ZPT, neumožňují v pravém slova smyslu odělit kód od HTML, protože JSP tagy nejdou součástí HTMP tagů jako v ZPT.

Osobně bych ZOPE zařadil někde na úroveň Domino serveru.(samozřejmě neobsahuje vše co má Domino), ale jde osystém vývoje. Zde mluvím z vlastní osmileté zkušenosti s Lotus Notes.

ne, Zope neni jenom hracka, Zope je totiz pekna s*ka ;)

tohle rikam z pohledu uzivatele, ktery byl prinucen pouzivat Zope u admina, ktery ho neumi nastavit...

kdo nemusel nikdy uploadovat 200 souboru pomoci weboveho rozhrani po jednom, nepochopi

A co takhle vyuzit webDAV, ktery ZOPE podporuje. V tomto pripade oznacite vsechny datove objekty, ktere chcete uploadovat a spustite upload pouhym pretazenim oznacenych objektu na plochu weboveho prohlizece. Z prohlizecu podporuje webDAV MSIE tusim ze jiz od verze 5.5

No, ve clanku o ZPT jsem teda cekal vic, nez popis jednoho tagu ;-).

Co me teda pobavilo predevsim, je 'souhrn vyhod Zope ve srovnani s konkurenci'. Zadne srovnani s konkurenci tam neni. O jakekoliv konkurenci jsou tam pouze vagni reci typu 'konkurence podporuje malo, pokud vubec'.

Nerad bych, aby doslo k mylce, Zope je pekny produkt, ikdyz ma sve mouchy. Ale po precteni clanku jsem dospel spis k zaveru, ze je to skryta reklama na firmu, na jejichz strankach je to 'srovnani'.

Mate pravdu, jeden tag nestaci.

Proto take brzy vyjdou dalsi dily, kde to bude rozebrano podstatne vic do hloubky. Ostatne v textu je napsano ze se jedna o serial, ale jen na jednom miste, takze jste to asi prehledl.

ok, privitam dalsi dily, docela me to zaujalo, az budu mit nejaky vetsi dynamicky projekt tak mozna pouziju zope, v tom pripade bych uvital v dalsim narazky na to jak se to pouziva z hlediska designera, programatora a system mamagera. Zrovna treba zope pekne oddeluje obe ulohy, jake jsou s tim zkusenosti v praxi?

PHP si lze tez takto prizpusobit, sam pouzivam sablony jiz dlouho. Musel jsem si akorat napsat vlastni "Zope". Funkci echo vubec nepouzivam, pripadny nezadouci vystup (mimo <? a ?> tagy) se bufferuje a posila jako specialni promenna do sablony - lze ho vyuzit (napr. pri ladeni), ale take potlacit. Takto mohu odesilat http hlavicky kdykoli. Jen misto volani funkci v sablone pouzivam pouze promenne (zda se mi to prehlednejsi a praktictejsi). HTML vlozene za behu do sablony je pak uz ciste objektove, bez jedineho tagu v kodu. Delat celou stranku obektove bez sablon jsem zkousel, ale rezie je prilis vysoka a nikdo se v tom nakonec nevyzna. Navic editace takovych stranek neni mozna.
Chci tim jen rict, ze neni nutna Java (na vetsine hostingovych serveru stejne neni a nejspis ani nebude), totez lze udelat v PHP.

budte si jisty, ze pokud na mnoha hosting serverech java neni tak brzo bude nebo to neni potreba, nebot veliky projekt, ktery si napr. nekdo necha napsat uz mu stoji i za vlastni vyhrazeny server a nestoji o sluzby hostingu.
rozmanitost je kazdopadne ku prospechu veci a je dobre, ze existuje mnozstvi app. serveru jako tomcat, jetty, zope, ...
pro me je java kazdopadne lepsi volba:
- standardizace jazyka (aby se jako v php pri prechodu z verze x na y nestalo, ze mi interpreter verze $x vyhodnoti vyraz jako true a v $y jako false),
- bezpecnost
- enormni podpora ze stran firem/projektu jako IBM, GNU (gcj), projekt jakarta@apache (ooobrovity framework - namatkou prave servlet & jsp kontejner tomcat, regexp, lucene ( vyhledavani v textech ), velocity, ... viz. http://jakarta.apache.org), samozrejme SUN

ano, muzete si vybirat co pouzijete, neda se rict, ze by prave jeden konkretni produkt/technologie byl/a pouzitelny/a vsude. da se rict, ze spoustu veci napisete s vetsim ci mensim usilim jak v php, tak jave nebo cemkoliv jinem (cgi), ale java je a zustava asi nejlepsi volbou (i diky otevrenosti - nikdo vam nebrani si nejpomalejsi cast prepsat do C a spolupracovat skrze JNI).

tot muj pohled na vec, p.

...bohužel, nemám tolik znalostí o jave jako Vy, ale každopádně co se týče vzájemné kompatibility, tak bych se zde zrovinka s javou nad PHP moc nevytahoval. Jistě, nelze dost dobře porovnávat interpretovaný jazyk s ""plnohodnotným oo jazykem"", ale několik větších aplikací jsem již pod javou rozcházel a věřte, dohledávat jaká verze od jakého dodavatele je potřebná, pro tu, či onu aplikaci je poměrně otravné.
U bezpečnosti především záleží na programátorech, jsou-li schopni bezpečnostní prvek do systému korektně implementovat, či ne. Bohužel, nejslabší článek u PHP je kvalitní IDE, kterých je naopak pro javu nespočet. Existuje sice PHP Coder, Zend IDE, PHP Edit a další, ale bohužel, ještě to není ono.

Mějte všichni příjemné Velikonoce!

jen si dovolim poopravit, java neni standartizovana!
sun stahl javu z ecma a tudiz vam nikdo zadny standard nezaruci :-)

ale jinak je java fajn a urcite se jako jazyk pro aplikacni servery velice hodi

i kdyz ja osobne pro dynamicka webova rozhrani nejradeji ASP.NET (hlavne nezacinejte flamewar, proste se mi to libi, muj osobni nazor a vymluvit si ho nedam :-)

Flame, flame, FLAME!

Fry, diky, zes mi usetril psani.

Hele, jsou v roce 3000 jeste Windows? :-)

Jsou, pouzivaji se jako OS hyper ultra inter zachodovych autosplachovacich mis.

Skoda ze obcas spachuji, i kdyz se do nich nikdo nevy* a obcas zase splachnout jdou jen po stisknuti packy pri soucasnem drzeni zachodoveho prkynka a kopnuti do misy.

Tady nejde o vlastni nazor, tady jde o podporu hnuti smerujiciho k potlacovani zakladnich lidskych prav, svobod a pudu.

Samozrejme mate pravdu, ze PHP nebylo primarne OOP. Taky mne to na nem stve, ale ze vseho nejvic mne stve mnozstvi "->", stredniku, zavorek... Kdyz uz se u Zendu inspirovali v C, mohli udelat jazyk bez techto problemu.
Vydali se vsak cestou MS-DOSu, tj. nejdriv to udelame ocesane a pak budeme vylepsovat pres Win95 az k WinXP, z cehoz plyne jak masove rozsireni, tak i nekompatibilita verzi.
PHP je, myslim, pro hostingove servery bezpecnejsi, protoze nedovoli, uz ze sve omezene podstaty, delat nic jineho :)
Presto jsou velke projekty v PHP (viz centrum.cz), ktere bez problemu funguji, ono je to o tom, jake "zaklady" si vybudujete. V Jave je mate jiz od vyroby.

Nechcem tu vyvolavat dalsie plamene nenavisti, ale len pridat skusenosti s roznymi jazykmi a nastrojmi pre vytvaranie stredne velkych databazovych aplikacii pre internet. Mam dlhorocne skusenosti s jazykmi ASP (VBScript a ActiveX komponenty), ColdFusion, PHP, Python a Java.

1. technologie od M$ - M$ vam da pekne vyvojove prostredia ale nic vas nenauci o spravnej architekture webovej aplikacie, softwarovom inzinierstve atd. Taktiez som bol castokrat nestastny z bugov ktore obsahovala technologia ASP (rok 1998).

2. ColdFusion - prijemny tagovaci jazyk. Velmi spolahlivy, lahko pochopitelny pre vsetkych (admin, programator, designer). Bohuzial komercny produkt a drahy, t.j. prakticky nepouzitelny v CR a SR. (1998- az do dnes pre projekty v zapadnej EU)

3. Python a ZOPE - Moje stretnutie s nim prebehlo v roku 2001. Toho casu to bola zaujimava technologia, ale po niekolkych mesiacoch sme od neho upustili. Chcete vediet preco? Mala rozsirenost jazyka Python a teda aj hotovych komponent a nastrojov. Zo strany zakaznika boli pozadovane interface na ine webove a serverove aplikacie, co bohuzial bolo toho casu v Pythone nemozne. Taktiez s podporou databaz to bolo slabe. Rovnako musim suhlasit s pripomienkou, ze programovat webovu aplikaciu len cez webove rozhranie je velmi neprakticke. No tych neprijemnych zisteni bolo este viac ...

4. PHP - Tento jazyk je to prave pre male projekty obzvlast pre podmienky SR. Jeho sila je prave v OpenSource. Pre vlastnu potrebu sme dokonca portovali niektore principy architektury webovych aplikacii ziskane z Javy. Konkretne sa jedna o MVC (Model-View-Controller, napr. http://www.eocene.net, http://sourceforge.net/projects/phpmvc), pouzivame templatovaci engine SMARTY (http://smarty.php.net/) a transparentnu databazovu vrstvu na baze ADODB (http://php.weblogs.com/ADOdb). Pre vyvoj pouzivame vynikajuce Eclipse (http://www.eclipse.org) s pluginom PHPEclipse (http://sourceforge.net/projects/phpeclipse/).

5. Java - bez dlhych reci: Ak potrebujete technologiu pre vacsi projekt, tak jedine Java. Java vas "nenecha na holickach". Za tymto tvrdenim si 100% stojim. Na baze J2EE sme realizovali velky B2B web s napojenim na rozlizny software (napr. SAP, CommerceOne). Neviem si predstavit ako by sa take nieco robilo v PHP alebo Pythone.

6. M$ .NET - nemam prakticke skusenosti.

Praktické zkušenosti - poučili se z Javy, JSP a servletů, spoustu věcí předělali, je to výborné. Navíc se tam opravdu krásně nechá oddělit programový kód od rozhraní - jenom prostým použitím dědičnosti, neboť šablony jsou obvykle založeny na třídách umístěných ve zkompilovaných knihovnách, čili můžou dědit proměnné, volat funkce atd.
Bohužel Mono (opensourcová verze Frameworku) je stále ještě v plenkách, alespoň z pohledu vývoje pro ASP.NET (byť už existuje i raná beta modulu pro Apache), takže v současné době je .NET použitelný jen pod Windows. Prý už je alespoň nějaký ASP.NET modul pro Win32 Apache, ovšem není free. Na druhou stranu pokud vím, už jsou k dispozici pluginy pro nemicrosoftí IDE, před časem jsem viděl třeba nějakou C# podporu do Eclipse.

tal je velmi silny nastroj, bohuzel, jeho (mnohdy velmi neprijemnym) omezenim je nemoznost rekurentniho vkladani tagu pri generovani dynamickeho obsahu. takze strom navigace se musi "natvrdo" (tzn. i s tagy <div></div> ci <ul><li>...</li></ul>) generovat scriptem, cimz trpi nezavislost obsahu na prezentaci.

No nevim jestli mi tam neco uniklo, ale stejneho efektu (tedy spojeni dat se sablonou) muzu dosahnout i prez XSL styly. Aplikace jednoduse vyleje data v XML (nemusi jit do souboru, staci kdyz to bude v nejakem DOM stromu) a sablona bude psana v XSL (opet muze viset v pameti v DOMu). Tohle reseni ma navic vyhodu v moznosti rozsireni o dalsi sablony (treba vystup pro tiskarnu s pouzitim XSL:FO, nebo vystup do TeXu, nebo do WAPu (kdyby ho nekdo pouzival), nebo celkem kamkoliv jinam.. ). Efektivita nebude IMHO o nic horsi nez s nejakym ZOPEm nebo JSPckem, XSLT procesory jsou -diky Bohu- k dispozici i napsany v <flame>jazycich pro normalni lidi</flame>.

K tomu mam jenom drobnou poznamku. Z vlastnich testu jsem rozhodne nedospel k zaveru, ze by XSLT bylo neco, co se da po strance vykonu nasadit na noncoffee-time pouziti ;-).

Ja jsem si delal taky svoje testy, i kdyz pochopitelne zalezi na komplikovanosti sablony, ktera podle meho v mem pripade nebyla nijak vysoka, ale zkratka u me dopadly az prekvapive dobre. Pouzival jsem obycejny libxml2&libxslt (ten standardni program na transformace se tam jmenuje myslim 'xsltproc'). Ale divil bych se, kdyby mel ZOPE nejaky supr-trupr optimalizovany vyplnovac sablon. Me se na tom reseni libi predevsim to striktni oddeleni dat a vzhledu, odstraneni redundanci (v datech) a tak..

Co to je za blbost, ze ASP neoddeluje data od prezentacni vrstvy?To je stejne jako kdyby nekdo rekl, ze C++ neni objektovy jazyk jenom proto, ze se v nem da naprasit normalni strukturalni program bez jakyhkoliv objektu. Autor clanku se IMHO v tematice orientuje valice,velice povrchne.

To je fakt.. akorat ze kdyz je neco shit, tak tomu nepomuze ani moznost oddeleni dat od prezentacni vrstvy, porad to bude shit, zejo.

... no neviem, ale ja uz nejaky rok programujem "vecsie" aplikacie na webe, pricom som pouzil PHP, javu, aj MS Studio. Kazde z tychto rieseni je dobre. ale samozrejme kazde z nich je dobre na nieco ine - samozrejme. php - rychlo napisana aplikacia, ak ide o "one man show" nepoznam lepsiu volbu. JAVA - velmi sikovna vec, velmi dobra vec pri tvorbe projektu vo velkom teame (nezalezi na OS, bezi a kompiluje sa to prosto vsade), len pripomeniem - napisal a kompiloval na WIN, testoval na LINUXe a nasadil u zakaznika na HPUXe (instalacia prebehla kopirovanim cez ftp samozrejme) ... no neviem ale mne sa to zda ako fakt dobre. MS Studio - velmi pekny nastroj, vykonny, pohodlny na pisanie, dobre prepracovany ... len jedna "nevyhoda" - funguje len na MS a stoji dost vela prachov ... z komercneho hladiska dost drahe za dany efekt - naco platit za nieco za co sa nemusi platit? :o)

Pote, co jsem si precetl vsechny vyse uvedene nazory jsem dospel k jedinemu zaveru. JAK SNADNO SE HODNOTI NECO O CEM NIC NEVIM!

Python srovnavat s PHP je temer zverstvo. Python je jazyk, ktery ma vyborny navrh, je rychly a da se v nem naprogramovat temer cokoli. Nehrozi u nej nejake drasticke zmeny, kazda zmena ma svuj pevny rad, takze o ni budete vedet o dva roky drive, nez ohrozi vase programy!

Zope pak je aplikacni server napsany v Pythonu. Nad Zope beha mnoho dalsich produktu vcetne treba publikacniho systemu Plone atd. Nekdo si stezoval na nepohodli pri uploadu 200 souboru. Kdyby ho napadlo podivat se po webu, usetril by si cas, co treba LocalFS Product, builtin FTP server atd? Tim vsim by to byla hracka.

Komunita lidi kolem Pythonu a Zope je obrovska. I v Cechach existuje skupina lidi PyCZ, kteri se venuji Pythonu a Zope. Nikdo z nich by nevypustil takove bludy, protoze Zope a Python prakticky pouzivaji a vedi o jejich nedostatcich a prednostech!

Vies Honzo, ja som bol tiez mlady studak. Suhlasim ze Python je krajsi a rozhodne kvalitneji navrhnuty jazyk ako PHP, ale to nestaci na to aby som v nom okamzite zacal programovat komercny soft. Ked skoncis skolu a zacnes sa programovanim zivit 24 hodin denne, tak to zistis sam. Ak sa ti podari zivit s Zope, tak klobuk dole.

Mozna ze moje reakce byla prilis "uderna", ale dokazi me nastvat zastanci PHP a to dosloval. Zope osobne nepouzivam (mam k nemu nektere osobni vyhrady), jen jsem vypsal nekolik reakci, ktere bezely nekolikrat v konferenci python@py.cz, ale Python je v dnesni dobe jazyk, ktery se jiz zacina prosazovat u komercnich firem. Z Ceskych je to DataPartner nebo treba Seznam, svetove pak Google a dalsi, ktere jsou na domovskych strankach Pythonu. A ke vsemu - Python neni jen jazyk, ale i testovaci platforma pro Javu, skriptovaci jazyk pro aplikace, jazyk pro numericke vypocty a spoustu dalsiho.

Programovanim v Zope se zivim. Diky za smeknuti klobouku, ale to nemuselo byt. Studentem uz 13 let nejsem. Firem, ktere v Pythonu programuji komercni soft neni malo, a nektere se soustredi VYHRADNE na python.

Google je Vas kamarad, pouzivejte ho :-)

Na urcity veci je to podle mne velice sikovna zalezitost, ale uz z principu mi prijde, ze je to pomaly.
Jedna vec je, kdyz to nasadite na firemni web s relativne malou zatezi a druha, kdyz na tom pustite HODNE navstevovany web.

Muze se k tomu nekdo vyjadrit?

Asi takhle:
Je to abstraktni vrstva, ktera zprehlednuje a procistuje design aplikace, a tim zlepsuje tvorbu a udrzbu sw. Ale musi se to dobre navrhnout.
Kdyz ma aplikace zpracovavat nejakou narocnou logiku, tak na to beztak musis mit nadimenzovanej stroj, protoze se to proste musi spocitat a musi to vychazet z dat, ktery zadava uzivatel v predem neurcenym okamziku.
Pokud to ma neco prezentovat nebo zobrazovat, tak budes asi beztak nekde neco nejakym mechanismem kesovat, a to nejlepe v okamziku, kdyz mas hotovo (treba nad datovou vrstvou, treba finalni html). S tim sou samozrejme spojeny urcity problemy a napsat inteligentni cache rozhodne neni sranda.
Pojem "velka zatez" je dost relativni. Na opravdu velkou zatez mnohdy nestaci ani php, ani asp, ani jsp . Zalezi na mnoha faktorech.

Na adrese http://www.zope.com najdete referencni zakazky od opravdu velkych firem, vcetne U.S.Navy.

Pokud Vas zajima, jak lze resit problemy vykonnosti pro silne zatizeny web: pomoci inteligentniho cachovani na strane serveru (Zope podporuje dve metody takoveho cachovani), a pomoci ZEO. ZEO je neco jako clusterove reseni, pricemz jednotlive prvky clusteru mohou byt libovolne zemepisne rozlozene.

Dalsi informace o ZEO a cachingu najdete v Zope Book, ktera je na http://www.zope.org.

Pridavam se k vyctu tech, ktere Zope zivi.

1. Proc jste opominul DTML? DTML neni mrtve jak si mysli skalni zastanci ZPT, naopak umoznuje daleko vice nez ZPT, navic je mnohem rychlesji. Pravda, zakladni filozofie nepocita tolik s duslednym oddelenim logiky a prezentace, nicmene co jste nam ukazal se ZPT neni vubec oddeleno, ba naopak je pevne integrovano do designu. DTML lze pri vhodnem zpusobu prace mit take oddelene od prezentace, jedine co designer uvidi, je proste "nejaky" tag. Takove stranky se daji editovat bez uhony i v MS Frontpage.

2. znate ESI? www.esi.org



JL.

1. DTML jsem neopominul. Tento serial clanku zkratka neni o celem Zope. Je zameren pouze na Zope Page Templates. Takze tam nebude podrobne rozebrano DTML, ZSQL, Structured Text, ZCatalog ani jine soucasti Zope. Budou zmineny strucne podle potreby, ale jejich popis nebude rozsahly.

2. O ESI jsem cetl jen zakladni informace.