Strč prst skrz AbcLinuxu - I

9. 4. 2003 | Leoš Literák

Články - Strč prst skrz AbcLinuxu - I  

aneb pohled pro programátory do útrob našeho serveru.

Právě začíná dlouho slibovaný seriál pro programátory, kteří se chtějí dozvědět něco více o tom, jak je AbcLinuxu napsáno a jak funguje. Kdoví, pokud bude zájem, možná i zveřejním zdrojové kódy a umožním na něm pracovat i případným dobrovolníkům. Nápadů na vylepšení mám spousty, ale času málo .

Základní informace

AbcLinuxu je naprogramováno v Javě na základě vybraných J2EE techologií za použití moderních programátorských přístupů. Architektura je postavena na pull variantě MVC (Model-View-Controller) patternu. MVC je léty prověřený přístup k vývoji GUI aplikací, kdy aplikace je rozdělena na tři části. Model reprezentuje data, View slouží pro interakci s uživatelem a Controller je zodpovědný za zpracování uživatelských požadavků. Pull varianta je jeho rozšířením, ve kterém Controller tlačí data do View, takže ve View máte přístup jen k těm datům, které vám Controller zpřístupní.

Model je postaven na základě objektů majících společného předka - GenericObject. Tato data jsou ukládána přes JDBC do databáze MySQL. Pro zvýšení rychlosti je na vrstvu persistence navázána transparentní cache.

Jako View v současnosti slouží knihovna Velocity, ale kvůli jejím nedostatkům a nulovému vývoji přecházím na FreeMarker. Obě knihovny definují svůj vlastní programovací jazyk, který se podobně jako PHP zapisuje přímo do html souborů. Jazyky jsou velice jednoduché, koneckonců šablony (jak se kombinaci html a těchto jazyků říká) by měli vytvářet designeři, nikoliv programátoři.

Konečně poslední zásadní částí architektury je Controller. Zde se jedná o několik desítek servletů. Ty mají na starost zkontrolovat vstup od uživatelů (HTTP request), zpracovat jej (například uložit komentář či vytáhnout článek z databáze), zvolit šablonu a vykonat šablonu. Její výstup je pak vrácen prohlížeči.

Motivace

V dnešním díle se budeme hlouběji zabývat modelem. Nejdříve se pokusím vysvětlit své cíle a požadavky, aby bylo jasné, proč model vypadá zrovna takto.

Když jsem propgramoval AbcLinuxu, měl jsem již dostatek zkušeností s projektem Linux Hardware. Tento projekt umožňoval ukládat hardwarové záznamy do stromové struktury a později bylo přidáno diskusní fórum. Databáze byla naprogramována účelově a pro každou novou službu bylo nutno přidat nové tabulky. Vytváření vazeb mezi tabulkami bylo velmi obtížné. Neexistovala žádná separace do MVC a jedna php stránka měla na starost jak manipulaci, tak zobrazování dat. Proto přidávání nových služeb bylo prakticky nemožné.

Mým hlavním požadavkem tedy byla maximální flexibilita. Chtěl jsem mít možnost vytvářet vazby mezi libovolnými objekty, snadno přidávat nové služby a upravovat existující objekty. Mou noční můrou z časů Linux Hardware bylo, když po mně někdo chtěl přidat další údaj k hardwarovým záznamům. Znamenalo by to úpravu tabulky v databázi a kontrolu všech databázových příkazů. Proto jsem se rozhodl, že vlastní data budou uložena v podobě XML, v tabulce reprezentované jako BLOB. Takto mám zachovánu zpětnou i dopřednou kompatibilitu .

Z Linux Hardware se mi osvědčilo členění dat do stromu. Například Procesory / Intel / Pentium III / Pentium III 750 MHz. Proto jsem chtěl tuto vlastnost nejen zachovat, ale vytvořit ji univerzálněji. Abych mohl vytvořit vazby mezi libovolnými objekty, i těmi, které ještě neexistují. V Linux Hardware byly tyto vztahy natvrdo zapsány do tabulek. Například záznam měl jako políčko číslo položky, položka zase obsahovala číslo kategorie, ve které je umístěna. Ale co když jsem chtěl mít jednu položku ve dvou kategoriích? Řešením je nový objekt Relation.

Popis tříd modelu

Každý objekt modelu je potomkem GenericObjectu. Proto všechny objekty sdílejí jeho vlastnosti. GenericObject má dvě hlavní vlastnosti (properties). Prvním z nich je id. Jedná se o identifikátor objektu, který spolu s třídou jednoznačně objekt identifikuje. Druhou vlastností je content, což je seznam relací, ve kterých je objekt předkem. Relation je objekt definující vztah mezi dvěma objekty. Každý objekt tedy může mít libovolný počet libovolných potomků, stačí vytvořit mezi nimi relaci. Jedná se o Composite pattern.

Na následujícím obrázku je zobrazen UML diagram tříd v AbcLinuxu.

Než se dostanu k detailnějšímu popisu jednotlivých tříd, měl bych se zmínit o způsobu, jak je řešeno XML. Jak jsem se již zmínil, v databázi je XML uložen jako blob data. Třídy, které jej používají, musí implementovat rozhraní XMLContainer. Takto získávám uniformní přístup ke stejným datům. Protože pětkrát implementovat stejnou funkcionalitu je nesmysl, vytvořil jsem třídu XMLHandler a zmíněné třídy (User, Relation, Category, Item a Record) ji používají (viz asociativita v class diagramu). XML je fyzicky realizováno pomocí stromu knihovny DOM4J.

GenericDataObject je společný předek tříd Category, Item a Record. Kromě instance XMLHandleru obsahuje vlastnosti owner (id vlastníka), type (dělení na podtypy) a datumy created a updated (kdy byl objekt vytvořen, respektive naposledy upraven). Category reprezentuje jednu sekci stromu, Item zase položku (hlavička článku, položka hardwaru apod). Konečně Record reprezentuje jeden záznam, jedná se vždy o list stromu a je potomkem Item.

User uchovává uživatelské profily. Z důvodu lepší efektivity a přehlednosti jsou některé jeho vlastnosti uloženy mimo XML. Jedná se o login, name, email a password. Vše ostatní je v XML. Relation obsahuje dvě hlavní vlastnosti - parent a child. Náznak obousměrného seznamu je vytvořen skrze vlastnost upper, která obsahuje odkaz na rodičovskou relaci. Zbylá data (možnost předefinovat ikonku či jméno potomka) jsou opět uložena v XML.

Poll je objekt obsahující ankety a v budoucnu i hodnocení článků. Má dvě logické vlastnosti - multichoice a closed. Ty určují, zda je povoleno dát hlas více možnostem, respektive zda je vůbec možné ještě hlasovat. Položky jsou uloženy v separátním objektu PollChoice. Není to optimální implementace, ale nechtělo se mi ručně předělávat staré ankety z Linux Hardware. Teď toho začínám litovat.

Server drží informace o cizích serverech, ze kterých stahujeme aktuální články. Link obsahuje data o externí informaci, například nejnovější článek na Rootovi. Můj původní záměr byl však mnohem širší, chtěl jsem vám dát možnost přidávat URL do systému. Konečně Data je další nedodělek. V Linux Hardware bylo možné přidávat k položkám obrázky, například snímek scanneru. Data byla určen právě pro tyto účely. Bohužel jiné věci měly prioritu.

Související články

Proč právě Java?
AbcLinuxu pro programátory aneb od PHP k Javě

Odkazy a zdroje

Java
Velocity
FreeMarker
DOM4J
Jakarta

Seriál AbcLinuxu pro programátory (dílů: 4)

První díl: AbcLinuxu pro programátory aneb od PHP k Javě, poslední díl: Strč prst skrz AbcLinuxu - II.
Předchozí díl: Proč právě Java?
Následující díl: Strč prst skrz AbcLinuxu - II

Diskuse k tomuto článku

[Martin Krauskopf]

Vybornej clanek, diky. Akorat jsem si pres noc rikal, jak je abclinuxu napsany (obdobnej sever, napsanej nad java platformou, v nasich vodach neznam/nenavstevuju). Uz se tesim na dalsi dil a urcite bych uvital i zdrojovy kody. Urcite by to bylo zajimavy "cteni" a zaroven to muze poslouzit i autorovi (aneb opensource ma nejmin bugu :). A kdyz jsme u tech bugu, kliknu jsem na "Vlozit prvni komentar" a pak jsem dal "na chvili" back a text se zmenil na "Vlozit dalsi komentar" a na titulni strane se objevilo pod hlavickou clanku "Kometaru: 0". Tak nevim jestli je to bug nebo featura :) Kazdopadne urcite se primlouvam za ty zdrojaky a tesim se na dalsi dil.

[Martin Krauskopf]

ten bug/featura: viz "Kometaru: 0" pod hlavickou clanku "Jaderné noviny 211" na titulni strance.

[Leoš Literák]

feature prvni clovek, ktery zacne psat diskusi, ji i vytvori (prazdnou). vsichni ostatni, kteri si pak prohlizeji stranky, uz maji ve formulari cislo diskuse a to se pak nemusi hledat ..

[Martin Krauskopf]

aha, neco na tom bude, chytre! ;) a prave kvuli takovejm prkotinkam se tesim na dalsi dil a na zdrojaky. abych nemusel znovu venalezat kolo :)

[Leoš Literák]

bohuzel jsem nepocital s tim, ze nekdo zacne psat komentar, ale neulozi jej. pak jsou tam clanky s diskusemi o 0 komentarich

[Martin Krauskopf]

neudelal jsem to schvalne :/ PS: nestacilo by v prezentacni vrstve pridat naky if (diskuze.isEmpty()) resp. prislusnej jspTag? ja vim, ten cas :)

[Leoš Literák]

spise by me zajimalo, zda by nekdo mel zajem programovat AbcLinuxu. tech tasku je spousta, od jednoduchych na par radku (pridat perex do RSS) az po slozite typu predelat cache, security model ci udelat obousmerne news rozhrani k diskusim.

[Martin Krauskopf]

Osobne si myslim, ze by zajemcu bylo spousta :) Me ta "nabidka" urcite zaujala. Ale co mi chybi, jsou ty zdrojaky (to je hrozny jak se opakuju :) ). Takhle naslepo vubec nevim, jestli bych na to treba mel (tak co se vubec staram? :) ). Predstavoval bych si to asi tak, ze bys vypustil zdrojaky (treba GPL/APL nebo treba i LGPL, v tom odbornik nejsem) a zajemce by si je pak stahnul, prostudoval a statecnejsi by si precetli TODO a ty nejstatecnejsi by se do toho treba pustili a posilali by ti patche/navrhy/zaplaty. Ale takhle muzu jenom rict "zajem bych mel, ale". Je to asi jako vsechny OS projekty. Lidi to pouzivaj, pak zacnou koukat do zdrojaku a treba prispejou kapkou do mlyna :)

[Martin Krauskopf]

Na druhou stranu chapu, ze jen tak vypustit zdrojaky do sveta taky asi neni tak jednoduchy pocin.

[fikus]

ja navrhuju leosovi, aby nedaval zdrojaky jen tak svevolne, ale aby je nechal vytisknout na tricka. a kdo by chtel zdrojaky, by si koupil tricka a tim by leos vydelal penize )))

[stuff]

Skutecne rulezni napad, ale nevim jak ti na to Leos zareaguje

[Pavel Dobeš]

A kolik by tech tricek muselo byt? Stacilo by je poskytovat v palirne na CDckach, to by z toho byly financovany navic i jine projekty... PaD

[bhole]

clanok som este necital, iba uvod a hned ma napadlo. nie je to zbytocne pisat nieco taketo v jave ? imho to zbytocne viac zatazuje server (zelezo). imho php a mysql by potreby tejto pagesy uplne zvladlo. priam je nato urcene... ake su vlastne vyhody toho, ze sa to spravi v JAVA ?

[Martin Krauskopf]

no zacal sem psat, ale myslim, ze Leosuv clanek mluvi za vse. Viz. "Souvisejici clanky".

PHP sice neznam, ale myslim, ze nikdy nic :) nemuze nabidnout takovou modularnost, rozsiritelnost, cistej OO navrh a takovy mnozstvi 'standardu' a knihoven jako Java.

Nic mene blackhole.sk je taky velice pekne ;). De o to co obnasi udrzba a vylepsovani situ.

Nehlede na to, ze mam obcas pocit, ze kdyz neco udelam/navrhnu v Jave spatne, tak me po chvilce tak nakope, ze vlastne nakonec je vsecko naprogramovany/navrhnuty dobre :))

[Tomáš Tichý]

>nikdy nic :) nemuze nabidnout takovou modularnost, rozsiritelnost, cistej OO navrh a takovy >mnozstvi 'standardu' a knihoven jako Java.

<flame> A co Python? Mel jsem cest delat v Jave ale kdyz jsem poznal Python, za nic bych se nevratil. </flame>
Je pravda, ze jsem zatim nedelal ani s JSP & spol. ani se Zope, takze v tehle oblasti srovnavat nemuzu.

[Robert Krátký]

viz odkazy na souvisejici clanky.

[tomm]

Nedavno jsme se s kolegy ve skole rozhodovali co pouzit na webovou aplikaci. Zda PHP ci Javu. Potrebovali jsme OOP. Jeden z kolegu mel dobre zkusenosti s Javou a JSP, druhy s PHP. Nakonec zvitezila Java (i kdyz duvodu bylo vice). Ale dulezite bylo:
- rychlost vyvoje, asi nikdo nepopre, ze objekty v Jave jsou podstatne zmaklejsi nez v PHP
- vyssi bezpecnost
- snadna udrzba a modifikace
- vyssi vykon (ted asi hazim bombu, ale pokud jsou stranky jiz zkompilovane, tak je Java rychlejsi nez PHP). Leos by to mohl i vedet presneji Provozuje velky server, tak co na to rekne ???

A navic me se Java hodne libi. Presel jsem na ni s drobnymi vyjimkami kompletne a nemuzu si stezovat.

[Martin Perina]

Vubec se nedivim, ze byla pouzita Java, protoze pro velke serverove aplikace dnes neexistuje nic lepsiho (muj vlastni nazor, ale vyzkousel jsem si PHP, Python, .NET i CORBu, ale J2EE u mne vyhralo :) Akorat mne trochu zarazi, ze se nepouzivaji standardni knihovny pro WWW prezentacni vrstvu, tedy kombinace JSP/Servlet (at uz s JSTL/JSF nebo Struts). Vidis, Leosi, v pouziti Velocity nebo FreeMarker nejakou vyhodu oproti std. technologiim?

[Leoš Literák]

na internetu je spousta srovnani, prectete si nejake na freemarker.org nebo u velocity. navic prvni verzi jsem psal v jsp a byla zalostne pomala. nez se ten jsp zkompiloval, trvalo to vecnost. jasne, da se to resit predkompilaci, ale to jsem nezjistil, jak. a verze ve velocity byla dabelsky rychla .. dalsi vyhodou je, ze v jsp by vas mohlo svadet psat logiku do sablon. v techto enginech nemuzete PS. kazdy, kdo mi navrhuje php, se me dost dotyka. jako byste me nutili presedlat z jaguara do trabantu po dalsim dile pochopite, ze funkce abclinuxu v php NIKDY nenapisete (aspon ne rozumne brzy).

[jirka]

haha.. no to snad ne? z jaguaru do trabanta.. ha ha. ze mezi php programatory je vetsi podil lam neznamena, ze v nem nejdou napsat vetsi projekty ok ok.. dalsi dil beru jako vyzvu a chci videt jak pochopim, ze v php by to neslo promin, ale ted ses dotkl zase me

[Martin Krauskopf]

Taky by me zajimalo, jak dlouho Leos psal/prepisoval AbcLinuxu (treba muze zapocitat i dobu studia pouzitych technologii, apdb.). Myslim, ze by to taky byla zajimava informace, treba na ctvrt clanku :)

Jirka> myslim, ze dost dulezita je ta infomace v zavorce - aspon ne rozumne brzy.
Predpokladejme stejne dobry ridice :)

[b0rmann]

a co tak pouzit misto jaguaru B-52? bez vetsich problemu prepsal bych to v HTML::Mason pod mod_perl. a to i bez zdrojaku - staci kompletniho uml. jen bych vymenil mysql aspon na postgresql...

[Honza Kynčl]

Nebo ještě jedna B-52 a to Embperl /dříve známý jako HTML::Embperl. :)) Ale dost flamu uznávám že JAVA také není špatná.

[Zdeněk Pavlas]

Pull varianta je jeho rozšířením, ve kterém Controller tlačí data do View, takže ve View máte přístup jen k těm datům, které vám Controller zpřístupní.

"tlačení" je přece "push", nikoliv "pull. Napadlo mne že jde o pohled ze strany View, ale v té druhé větě je uvedeno explicitně že aktivní komponenta je Controller.