17. listopadu 2008

JSF - sestava sedmi statečných

V předchozím článku jsem zmínil naší sestavu sedmi frameworků resp. knihoven, které používáme pro vývoj s JSF. Některé knihovny byly dané již od začátku, některé se ukázaly jako nezbytné až v průběhu samotného vývoje.

  • Apache MyFaces - úplně na začátku jsme začali se SUNovskou implementací JSF, ale asi po měsíci jsme přešli k MyFaces. Jednak jsme měli pár problémů s NetAdvantage komponentama, které se přechodem vyřešily a jednak jsme dostali pocit, že MyFaces implementace "více" žije, že je lepší bug-fixing apod. Ale toto může být subjektivní. Používáme JSF verze 1.2.

  • NetAdvantage komponenty - o těchto komponentách jsem již něco napsal (1, 2). Snad jen dodám, že někdy v září vyšla nová verze podporující JSF 1.2, která zejména ve spojení s Facelets obsahuje celkem dost chyb. Hodně jsme přemýšleli, zda pokračovat nebo zkusit nějaké jiné komponenty a rozhodli jsme se pokračovat - reportovali jsme hodně chyb a teď víceméně čekáme na nový hotfix. Verze 1.1 a bez Facelets (platí pro obě verze) je mnohem více odladěná.

  • Tomahawk komponenty - primárně využíváme NetAdvantage komponenty, ale sem tam potřebujeme něco jiného nebo něco více. Například tagy t:htmlTag a t:div používáme celkem dost, protože NetAdvantage nedovolují používat čisté HTML ve svých tagách (i když používáme Facelets). Zkoušeli jsme také Trinidad, hlavně kvůli komponentě na výběr barvy, ale od toho jsme nakonec ustoupili - jednak je tato knihovna celkem invazivní (vyžaduje použití vlastního ViewHandleru) a jednak už jsme začali cítit, že těch knihoven máme v projektu nějak moc.

  • Spring framework - bez Springu si už nedovedu představit snad žádnou aplikaci, takže zde nebylo co řešit. Velkou výhodu to přineslo díky MyFaces Orchestra, která implementuje nové konverzační rozsahy pro Spring beany. Používáme Spring EL resolver, takže nemusíme skoro nic definovat přímo v JSF. O bezpečnost aplikace se nám stará Spring security.

  • MyFaces Orchestra - s pomocí Springu implementuje nové konverzační rozsahy, více v tomto článku.

  • Facelets - když už JSF, tak jedině s Facelets. Díky Facelets je JSF mnohem více stravitelnější, je to výborný šablonový systém. Při použití JSF s JSP resp. JSTL si je potřeba dát pozor na spoustu možných problémů (popsáno v tomto článku), které s Facelets odpadají.

  • URL rewriter - díky URL rewriteru jsme byli schopni vyřešit asi největší nedostatky JSF - nemožnost bookmarkovat stránky, nemožnost efektivního zabezpečení stránek pomocí Spring security a problém s "opožděnými" URL (uživatel vidí v prohlížeči URL, které odpovídá předchozí stránce). Také jsme tím mohli zcela vynechat konfiguraci navigace v JSF a nadefinovat jí (dle mého názoru efektivněji) pomocí URL rewriteru.

14. listopadu 2008

JSF zase nejsou tak špatný ...

Sice se zpožděním, ale rád bych reagoval na nedávno vydané články o JSF (1, 2). Možná bych spíše měl napsat doplnil místo reagoval, protože se vším co bylo napsáno souhlasím - na komponentovou technologii JSF jsem přešel teprve letos na jaře a přechod to byl celkem bolestivý. U mě to bylo ještě umocněný tím, že jsme si vybraly NetAdvantage komponenty, které mají celkem dost chyb, takže nebylo výjimkou, že jsem hodiny zkoumal proč něco jednoduchého nefunguje. Teď už si naše JSF sestava (MyFaces, NetAdvantage a Tomahawk komponenty, Spring framework, MyFaces Orchestra, Facelets, URL rewriter) sedla a už to celkem jde.

Chtěl bych uvést pár pozitiv, které jsem u JSF spatřil (nutno dodat, že výhody jsou zejména oproti request-driven řešením, než oproti jiným komponentovým technologiím).

  • JSF je J2EE standard - to má svoje velké nevýhody, ale i svoje výhody - technologie má zaručenou určitou životnost (velice důležité z pohledu investic), lépe se budou hledat programátoři na projekty, existuje určitá konkurence mezi dodavateli JSF komponent.

  • vzhled prodává - ať si každý říká co chce, ale vzhled je velice důležitá věc u většiny aplikací. I když NetAdvantage mají velké množství chyb a nedostatků, tak jedno se jim nedá upřít - jejich komponenty jsou pěkné. Komponenty jsou standardně nabízeny v asi deseti různých odstínech, stačí si jen vybrat nebo si upravit podle svého přání již existující.

  • rychlost vývoje - počátky vývoje aplikace byly hodně pomalé, ale od té doby, co jsme "prokopli" základní struktury stránek (detail, editace, výběr s modálním oknem apod.), tak jde vývoj velice rychle. Již v době návrhu obrazovek a výsledné podoby aplikace jsme věděli, že budeme používat NetAdvantage komponenty a podle toho jsme se to již snažili navrhovat. Teď navíc víme co funguje, co ne, takže jsme schopni navrhnout celkem rychle jakoukoliv stránku s tím, že ji také celkem rychle poskládáme a uděláme.

Nejsem určitě ten, kdo má rád JSF technologii, ale je prostě pár věcí, které s nimi celkem fungují.

3. listopadu 2008

Stromová data v relační databázi

Řešil jsem nyní na projektu uložení a práci se stromovou strukturou dat.



Každého asi napadne řešení, kdy objekt si bude držet referenci na svého předka. Toto řešení je funkční, ale má jednu velkou nevýhodu a tou je pomalost načítání stromu. To je dáno rekurzivním algoritmem a tedy velkým množstvím dotazů do databáze. Na druhou stranu je velice jednoduché přidávat nové objekty nebo je přesouvat. Tento model se označuje jako The Adjacency List Model.

Já jsem ale potřeboval "opačné řešení" - co nejrychlejší načítání stromu i za cenu toho, že při správě stromu si uživatel chvíli počká. Pro tento případ je ideální tzv. Modified Preorder Tree Traversal algoritmus. Ten si kromě odkazu na svého předchůdce eviduje další dvě pomocné hodnoty, tak aby sestavení stromu bylo co nejrychlejší. Naopak změny v hierarchii stromu mohou vést k nutnosti přepočítat pomocné hodnoty u všech objektů.


Více informací k uvedené problematice lze nalézt zde: