Zobrazují se příspěvky se štítkemPrezentační vrstva. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemPrezentační vrstva. Zobrazit všechny příspěvky

4. října 2012

Nástroje pro prototypování GUI

Pokud dneska navrhuji novou aplikaci, tak si to bez prototypování uživatelských obrazovek vůbec nedokážu představit. O to více se divím, že byli dříve časy, kdy jsem byl schopný si vystačit pouze s textem. Což samozřejmě nikdy moc dobře nefungovalo.
Je nutné minimalizovat nejasnosti a nedorozumění mezi vývojovým týmem a zákazníkem, předcházet neočekávanému. Je potřeba mít "něco" nad čím se můžu se zákazníkem bavit ještě dříve než vývojový tým začne programovat, "něco" co mi umožní získat co nejdříve zpětnou vazbu na to, jak to celé má vypadat a fungovat.

Z tohoto pohledu se mi jeví jako ideální drátěné modely (wireframes). Používáme k velké spokojenosti Balsamiq Mockup. Je to nástroj postavený nad flashem, nabízí jak webovou, tak desktopovou verzi, dokonce i pěkný plugin do Confluence a JIRY. Mezi všemi verzemi funguje bezproblémový export/import.



Při výběru jsme prošli a vyzkoušeli hodně nástrojů, na některé z nich přikládám odkaz a krátký komentář.

Balsamiq Mockup
  • Nástroj pro rychlý návrh mockup a drátových modelů.
  • Desktop aplikace, web aplikace, plugin do dalších systémů (Google Drive, Confluence, JIRA, XWIKI, …)
  • Desktop aplikace - 79$ na jednoho uživatele, Web aplikace – od 12$/měsíčně 
    Pluginy – ceny se liší v závislosti na použitém systému a způsobu licencování
  • Desktop aplikace – Windows, OS X, Linux, ostatní platformy s podporou Adobe AIR.
    Web aplikace a pluginy – Internetový prohlížeč + Flash 
  • Komplexní nástroj pro designéry.
  • Web aplikace - Internetový prohlížeč
  • Předplatné od 7$/měsíčně
Inpreso Screens
  • Nástroj pro vytváření kvalitních mockup modelů.
  • Desktop aplikace – pro chod aplikace je nutný Adobe AIR
    Web aplikace - Internetový prohlížeč + Flash
  • Omezená verze zdarma, předplatné 29$/rok na jednoho uživatele
  • Nástroj pro vytváření prototypů. Lze jít nad rámec vytváření drátových modelů a prototypů přidáváním událostí.
  • Web aplikace - Internetový prohlížeč
  • Zdarma
 GUI Design Studio
  • Nástroj pro vytváření návrhů pro prostředí Windows. Lze ho použít k rychlému vytvoření prototypů kreslením obrazovek s využitím standardních Windows prvků a jejich propojením, aby bylo možné následně simulovat chování.
  • Desktop aplikace – Windows
  • Od 129$ za jednu licenci
  • Silný nástroj pro vytváření drátových modelů aplikací.
  • Desktop aplikace – Windows, OS X
  • Desktop aplikace - Omezená verze zdarma
    Pro verze 495$ za licenci

  • Webový nástroj pro rychlé vytváření drátových modelů a prototypů GUI pro web, mobilních a podnikových aplikací. Umožňuje pohodlné testování použitelnosti a inteligentní spolupráci.
  • Web aplikace - Internetový prohlížeč
  • Předplatné od 9$/měsíčně
Další nástroje a odkazy bez komentářů:

5. dubna 2012

Zkušenosti s Bootstrap

Znáte Bootstrap, řešení pro prezentační vrstvu od Twitteru? My jsme ho měli možnost vyzkoušet na menším projektu pro administrační část a rád bych se podělil o naše zkušenosti:

  • Bootstrap jsem objevil někdy minulý rok na podzim a od té doby ho sleduji a je vidět, že se rozvijí, že žije. Množí se také informace na internetu, začíná se to používat. Např. článek To Bootstrap or Not?
  • nám se hodně libí jednotnost a jednoduchost celého řešení, nemusíme řešit jednotlivé prohlížeče, celkem rychlý vývoj. Úvodní konfigurátor je pak jen taková třešnička na dortu.
  • od začátku jsme měli jasno, že chceme Bootstrap použít jen na admin část a pro tento účel jsme byli spokojeni. Nicméně si nemyslím, že by to bylo vhodné řešení pro jakékoliv webové řešení, zejména pro ty složitější (např. naše snaha o výběr technologie na klienta).
  • náš technologický stack byl následující: Spring MVC, Freemarker, Sitemesh, Bootstrap, jQuery
  • jako nedostatek bereme nepřítomnost komponenty pro výběr datumu. Museli jsme tedy vzít tu z jQuery - nebyl to žádný velký problém, ale už jsme museli trochu řešit jednotnost vzhledu a upravovat to
  • další výtka míří k dokumentaci - na první pohled je moc pěkná, vše hezky vizuálně zdokumentované, ale pokud pak člověk jde do detailu, tak ty informace sem tam prostě chybí. V lepším případě je člověk dohledá na internetu a nebo nejsou. Vzhledem k tomu, že se jedná o firemní framework publikovaný ven, tak oni ve firmě to know-how zřejmě mají, jen se všechno nepodařilo zdokumentovat pro ostatní. Diskuzní fórum jsme nenašli.
  • kolegům se nepodařilo vůbec rozchodit dvě věci - Transitions (jQuery plugins) a hover popover.
 Máte vy nějaké zkušenosti z Bootstrap?

23. ledna 2012

Vybrat JasperReports nebo BIRT reports?

Potřebuji se rozhodnout, jaké řešení na reporty vybrat a pořád nevím. Nějaké porovnání těchto nástrojů jsem již uváděl na mém blogu, ale již je to skoro tři roky zpátky a od té doby se mnoho věcí určitě změnilo.

Pořád si myslím, že volba je mezi JasperReports a BIRT reports. Našel jsem další možnosti jako Pentaho Reporting, Crystal Reports nebo NextReports, ale žádné z těchto řešení mě moc nezaujalo.

Já osobně žádné pokročilé funkce od nástroje neočekávám, spíše ty základní:

  • reporty budou primárně zobrazeny na webové stránce
  • export do PDF, XLS je nutností
  • absolutní většina reportů bude statických, tedy uživatel klikne na odkaz a zobrazí se mu určitý report. Žádná velká interakce uživatele při zobrazování reportu nebude.
Můj favorit je JasperReports, ale asi jen díky nějakým subjektivním důvodům:
  • JaspeReports je tu už dlouho a již od nějaké 1.x verze Springu je součástí standardní podpory. Takže Spring nabízí podporu na podobné úrovni jako jiné prezentační frameworky jako Freemarker, Velocity atd.
  • velká komunita a rozsáhlá dokumentace (z uvedených nástrojů nejlepší)
  • myšlenka kolem JasperReports Serveru mi přijde zajímavá a bez většího úsilí nabízí velkou přidanou hodnotu
Moc pěkné srovnání je v článku BIRT, Jasper, Pentaho - Comparison Matrix nebo v článcích JasperReports, případně BIRT Vs Jasper Report A Comparitive Study.

Jaké máte prosím zkušenosti vy?

13. května 2011

Co vybrat na klienta? Konec prvního kola

Vítězem prvního kola se stal .Net, i když i GWT budeme chtít využít.

Jako první volbu pro přepis našich stávajících aplikací použijeme .Net platformu. To je zatím jedno jasné rozhodnutí, na kterém jsme se domluvili, a které nám dává smysl. Hned příští měsíc si v tom vyzkoušíme napsat jednu zcela novou aplikaci, abychom nabrali zkušenosti a získali cennou zpětnou vazbu.

Mezi hlavní argumenty pro .Net patří tyto:

  • možnost výběru cílové podoby aplikace (za splnění určitých podmínek během vývoje) - standalone aplikace vs. webová aplikace Silverlight
  • naši zákazníci jsou zvyklý na velký uživatelský komfort z našich stávajících aplikací, toto musíme i nadále dodržet
  • chceme řešit vývoj aplikací, ne řešit detaily GUI pro různé prohlížeče
  • většina vývojářů, kteří nyní dělali v Delphi, chtějí spíše .Net než něco jiného. Preferujeme know-how kolem řešené problematiky, než znalost samotné technologie.


Nicméně i GWT (asi) nezůstane stranou. Existuje spoustu oblastí a problémů, které není vhodné řešit jen .Net platformou, Silverlight je pro spoustu webových řešení těžkopádné a nevhodné. Proto mi dává smysl mít na výběr - buď .Net platformu pro naše produkty a nebo "čisté" webové řešení jako např. GWT nebo i třeba i něco jiného (zde ještě nemáme zcela jasno).

Firma má know-how jak ve vývoji tlustých klientů, tak i čistě webových projektů, proto mi přijde vhodné tohoto dále využít a stanovit pro firmu dvě nosné technologie. Navíc je to i slušná konkurenční výhoda, umět použít technologii podle zadání projektu a ne podle interních možností.

18. března 2011

Co vybrat na klienta? Finále Silverlight vs. GWT

Výběr klienta jde do finále, rozhodujeme se nyní mezi Silverlightem a GWT.

Potřeboval jsem tu původní množinu možností z prvního článku nějak zúžit, abych je mohl detailně porovnat a vybrat nejlepší variantu.

Důvody, proč jsem vybral tyto dvě technologie a nevybral jiné:

  • technologie nevybíráme úplně na zelené louce, nezačínáme od začátku - firma již má nějakou historii, má nějaké produkty, má nějaké know-how, má nějaké programátory, kteří mají určité znalosti. Není možné tedy říci, co bylo, to mě nezajímá, teď přichází budoucnost ...

  • současný výběr technologie ovlivní vývoj ve firmě na dalších min. pět let, možná i více. Ze zkušenosti potřebuji mít aspoň nějaké garance, že technologie tuto dobu (a ideálně mnohem déle) bude existovat, bude podporována, musím z ní "cítit", že se s ní do budoucna počítá. Proto jsem vyřadil řešení jako OpenLaszlo nebo třeba vaadin, které se mi zdají výborné, ale nedovolím si na tom postavit strategii firmy na další roky.
    Pozn.: možná by bylo vhodné uvést, že se bavím o firmě s více jak sto zaměstnanci, z toho čistý vývoj (bez konzultantů) čítá cca 30 lidí.

  • firma dosud hlavně vyvíjela tlusté klienty v Delphi, některé menší projekty mají webové uživatelské rozhraní. Servery jsou všechny psané v Javě. Toto má dva významné důsledky: přepsaní tlustých klientů do webových technologií nebude určitě bezbolestné a bude potřeba najít cestu nejmenšího odporu. Lidem se znalostí Delphi je bližší technologie .NET než webové technologie, navíc tu již nějaké znalosti .NETu jsou.

  • jak jsem již uváděl v předchozím článku, tak Java na straně klienta u mě (bohužel) důvěru nemá. Nikdy to nebylo ono, a ani JavaFX ve mě nyní nebudí moc velkou důvěru. Sun tuto technologii hodně tlačil, ale Oracle je nyní pro mě v této oblasti velkou neznámou.

  • výběr technologie souvisí s možnostmi sehnat (kvalitní) lidi s potřebnými znalostmi. Firma by se v tomto ohledu chtěla "otevřít" mladším ročníkům, absolventům. Také bude určitě dříve či později potřeba sehnat lidi pro nárazovou pomoc na projektech, takže je potřeba se dívat na její rozšíření a podporu v našich končinách.

  • základní technologie je jedna věc a nabízená rozšíření třetích stran je druhá věc. Např. samotné GWT dobrý, ale nabídka třetích stran ještě lepší - SmartGWT, ExtGWT atd. To samé Silverlight - telerik, infragistics atd.

  • při vývoji webových aplikací nechci řešit (nebo řešit co nejméně) kompatibilitu mezi prohlížeči. Chci používat nějaký produkt, nějaké komponenty, které to budou řešit za mě. Bohužel ze zkušenosti vím, že toto nikdy nebude 100%, viz moje zkušenosti z JSF a NetAdvantage.

  • na serveru bude Java, to je jistá věc. K Javě má určitě blíže GWT než Silverlight. Dnes máme celkem velkou znalostní propast mezi lidmi, co dělají klienta a co dělají server, protože se používají úplně odlišné technologie. Jen opravdu minimum lidí rozumí obojímu.
    Při volbě GWT budou mít oba světy k sobě blíže, bude možné lépe vytěžovat lidi - v případě potřeby podpořit více klienta nebo server. Teď to moc nejde, protože s Javou mi v Delphi nepomůžou a naopak
    Naopak pokud zvolím Silverlight a ty světy budou více oddělené, pak by mohl být větší tlak na kvalitní API na serveru, byly by jasně dané hranice. Až za pár let se zase třeba bude měnit technologie na klientovi, tak server zůstane beze změn a jen se vymění klient.

  • v dnešní době je určitě nutné přemýšlet o mobilním přístupu k datům. Není to hlavní kritérium, ale ohled na to je potřeba brát.

  • trochu mám obavu z přijetí Microsoftu u státních projektů. Je jasné, že Microsoft je u nás všude ve státní správě, ale přeci jen cítím, že státní projekty by měly být co nejvíce nezávislé a v tomto pohledu "mám lepší pocit" z Google než Microsoftu. Asi je to jen pocit.


Jdeme tedy do finále :). Zase budu moc rád za vaše komentáře a zkušenosti, protože takové věci jsou k nezaplacení.

17. března 2011

Porovnání RIA frameworků

Na předchozí článek Co vybrat na klienta? Html, flash, silverlight nebo JavaFX? reagovalo formou komentářů nebo emailů velké množství lidí a dokonce mi jeden z nich, Honza Kovář, poslal na toto téma svoji diplomovou práci - moc díky!

Uvádím pouze závěrečné srovnání, kde je vše hezky porovnané. Sice je z roku 2009, nicméně většina věcí stále platí a pro celkový přehled to vůbec nevadí.







Ještě přidávám odkaz na originální PDF.

8. března 2011

Co vybrat na klienta? Html, flash, silverlight nebo JavaFX?

Dneska se chci zamyslet nad výběrem vhodné technologie pro prezentační vrstvu pro náš nový projekt. Bude to spíše "manažerský" pohled než programátorský - nejde mi nyní moc o to, jak dobře se to bude programovat, ale spíše o to, jak moc to bude vyhovovat požadavkům projektu a firmy, kde nyní pracuji. Navíc ty technologie ani moc neznám.

Přehled požadavků, které je potřeba splnit:

  • projekt pro rozsáhlou státní organizaci. Cílové stanice nejsou pod kontrolou, nicméně je možné definovat nějaké podmínky pro běh aplikace (např. minimální verze určitých prohlížečů).
  • minimální nároky na administraci
  • potřeba přehrávání videa i audia
  • možnost ukládání dat na klientovi resp. držení nějakého stavu na klientovi. Možná bude potřeba i částečný běh v režimu offline.
  • interakce se souborovým systémem


Dle mého názoru připadají v úvahu tyto technologie: Adobe Flash (Flex), Microsoft Silverlight a nebo JavaFX, možná OpenLaszlo.

Uvedené technologie dále ještě více proberu a budou mě zajímat hlavně odpovědi na tyto otázky:
  • Jak moc daná technologie splňuje základní požadavky projektu?
  • Jak bude těžké ve firmě v dané technologii vyvíjet? Tedy jak moc je těžké někoho sehnat, jak moc je těžké se danou věc naučit, jak moc to zapadá do znalostí, které firma nyní má apod.? Ve firmě je velké know-how s vývojem Java serverových aplikací s tlustými klienty (Delphi, trochu .Net), částečně i s tenkými webovými klienty.
  • Jak vypadá celý "ekosystém" kolem dané technologie? Komunita, dokumentace, informace na internetu atd.
  • Jaké jsou možnosti zobrazení GUI v přenosných zařízeních?


OpenLaszlo jsem objevil teprve nedávno, na to se budu muset ještě více podívat, ale moc této variantě šancí nedávám.

JavaFX:
  • nemůžu si nějak pomoci, ale Java na klientské straně moc mojí důvěru nemá. Kolem JavaFX bylo hodně humbuku 1-2 roky zpátky, teď mám pocit, že se o tom už skoro vůbec nemluví (pohled na Google Trends mi to jen potvrzuje).
  • instalace a správa klientů bude asi v pohodě, pokud je aplikace podepsaná, tak může pracovat i se souborovým systémem. Možná prvotní instalace JRE bude vyžadovat admin přístup.


Adobe Flash:
  • velice rozšířené, multiplatformí, běží snad úplně všude
  • minimální požadavky na administraci resp. zásah adminů - flash plugin se instaluje zcela sám bez problémů
  • není moc velký výběr komerčních komponent pro aplikace (třeba Ribbon)
  • přijde mi dost těžké sehnat kvalitní lidi na Flash, navíc jsou skoro nulové znalosti ve firmě o této technologii
  • z pohledu státní správy mi Flash od Adobe přijde "méně bijící do očí" než Silverlight od Microsoftu.
  • stejně jako Silverlight by měl Flash splňovat všechny vstupní požadavky


Silverlight:
  • mnoho komerčních komponent (Ribbon)
  • prvotřídní podpora multimédií včetně 3D (zrychlené přehrávání videa s korekcí zvuku tak, aby bylo rozumět).
  • píše se v C#, hodně podobné Javě. Navíc směr, kam by firma chtěla do budoucna jít, protože stávající Delphi klienti již mají nejlepší léta za sebou.
  • pro první instalaci jsou potřeba administrátorská oprávnění
  • mám pocit, že Microsoft tuto technologii celkem tlačí a podporuje, i se o ní hodně píše a je prostě vidět. Očekávám, že má nejlepší léta před sebou.
  • pro mě zatím favorit, jen si nejsem jistý, jak moc dobře to bude běhat na Linuxech. Sice existuje projekt Silverlight MoonLight, ale Linuxové distribuce ho moc rádi nemají a pak je v implementaci cca rok pozadu oproti standardní windows verzi.


A co klasické HTML? Pokud bych výběr dělal za pár let, tak věřím, že bych volil HTML5, ale teď to bohužel k tomu není. Možná pokud se ukáže, že není potřeba držet žádný stav na klientovi nebo režim offline, tak se k variantě HTML vrátím. Samozřejmě čím "tenčí" klient, tím lepší.

Jaké máte zkušenosti vy? Jaké jiné výhody či nevýhody vás napadají pro dané technologie, co by jste mi doporučili? Předem moc děkuji.

23. dubna 2009

Komponenta pro vyhledávání, třídění, stránkování, ...

Vyhledávání záznamů a jejich zobrazení je tak často se opakující věc, že by se zdálo, že už to má každý vyřešený. Bohužel tomu tak není, některé problémy se opakují pořád dokola - je nutné zobrazovat celkový počet záznamů? Je nutné mít možnost přejít na poslední stránku výpisu? Je možné, aby se v průběhu stránkování nebo třídění měnila data? Stačí parametrické vyhledávání nebo je nutný fulltext? Těch otázek je mnoho a co aplikace, tak to trochu jiné (specifické) požadavky zákazníka.

Ve firmě, kde nyní působím, se snažíme najít vhodné řešení na následující požadavky spojené s vyhledáváním:

  • řešení by ideálně mělo implementovat prezentační, tak i datovou vrstvu. Tedy zobrazení dat a i jejich načtení.
  • zobrazená data by mělo jít filtrovat, třídit, stránkovat
  • použitelné v JSP
  • nezávislé na zvoleném MVC řešení. Pokud závislé, tak pouze na Spring MVC
  • na datové vrstvě podpora JDBC a Hibernate

Takové řešení znám zatím pouze jedno a jmenuje se ValueList. Tento projekt (již přes dva roky neaktivní) vychází z implementace J2EE patternu ValueListHandler. Poslední verze je 0.1.8, ale i přesto je použitelná. Ve firmě to používají již nějaký pátek, ale pořád to není ono, pořád je nutné řešit nějaké problémy kvůli specifickým požadavkům té konkrétní aplikace. Super ale je, že se analytické, vývojářské a grafické oddělení bylo schopno domluvit na jednom řešení, které se používá a všichni o něm vědí.

Já osobně toto řešení nepovažuji za zcela šťastné. Když pominu to, že ValueList obchází standardní strukturu několika-vrstvé aplikace (data se načtou a pak se hned zobrazují), tak mi přijde, že mě to příliš svazuje. Jak jsem již naznačil, někdy potřebuji fulltext, někdy musím zaručit neměnnost dat při stránkování, někdy tahám data z více datových zdrojů atd. Chci tím tedy říci, že nevidím velkou přidanou hodnotu v jednotném řešení na datové vrstvě, ale zejména na prezentační vrstvě, protože tam je to pořád stejné (až na úpravy vzhledu pomocí stylů).

Pro čistě prezentační vrstvu se hodí DisplayTag, který se zdá být hodně zajímavý. Jako vhodnou cestu tedy vidím v použití nějaké komponenty jako DisplayTag s rozšířením o filtrování a podpoře na úrovni MVC (ať nemusím pořád řešit převod parametrů komponenty na interní datovou strukturu, podle které pak vyhledávám) a s tím, že datovou vrstvu si budu řešit dle potřeby. Pro časté scénáře mohu mít nějakou podporu v datové vrstvě, ať se vše nemusí řešit od nuly.

Rád bych se zeptal, jak tuto problematiku řešíte vy? Máte nějaké osvědčené interní řešení nebo to řešíte v každé aplikaci znovu a znovu?

19. dubna 2009

Java Web Start vs. "normální" web

Minulý týden jsem se snažil napsat porovnání technologie Java Web Start s "normálními" webovými technologie jako jsou JSP, JSF, Velocity atd. Nešlo mi tedy o konkrétní webovou technologii, jako spíše o porovnání dvou světů.

Porovnání bylo pro mého kamaráda, který by rád určitou aplikaci a má představu, že JWS by mohlo být to pravé. Já sám se mu snažím nějak vysvětlit, že přeci jen "lehké" webové technologie jsou lepší. Ještě také dodám, že cílová aplikace bude interní resp. intranetová aplikace s max. počtem uživatelů okolo padesáti, určená pro správu několika registrů.

Web

  • + máme znalosti pro vývoj webových aplikací, HTML, CSS umí skoro každý
  • + lépe se bude navrhovat design
  • + spoustu věcí jsme již řešili, takže celkem významná znovupoužitelnost kódu a řešených problémů
  • + webový prohlížeč je snad na každém počítači, min. nároky na výkon počítače
  • + ovládání prohlížeče je běžná záležitost => pokud vytvoříme "standardní" webovou aplikaci, tak by běžný uživatel neměl mít problém
  • + lehce spravovatelná aplikace z pohledu nasazování nových verzí
  • + na jednotlivé stránky lze odkazovat a tyto odkazy se mohou posílat mezi uživateli
  • + dnes je jednoznačný trend přesunu aplikací do webového prohlížeče (např. Google Docs). Pomocí webových technologií lze dnes vlastně udělat aplikaci, která bude vypadat stejně a chovat se stejně jako desktopová aplikace.
  • - webové aplikace jsou bezstavové, takže nelze vytvářet (jednoduše) věci jako v desktopové aplikaci, navíc webové prostředí má své běžné problémy (návrat na předchozí stránku, refresh stránek po odeslání formuláře apod.). Vše lze ale nějak řešit.

Java Web Start

  • + centrálně spravovaná desktopová aplikace spouštěná přes JNLP (HTTP) protokol - je možné si např. dát odkaz na plochu počítače
  • - vývoj desktopové aplikace je složitější, navíc s ním nemáme moc zkušeností => vývoj bude nákladnější
  • - u JWS musím řešit navíc komunikaci klienta a serveru (pokud tedy bude oddělena logika a vlastní vzhled aplikace). Toto není u "normální" webové aplikace potřeba.
  • - při prvním spuštění nebo při nové verzi je vždy potřeba stáhnout celou aplikaci, takže to chvíli trvá dle rychlosti připojení k internetu
  • - uživatelé chtějí data na webu, takže je potřeba mít jednu aplikaci na správu dat a pak jinou aplikaci na její prezentaci, což je neefektivní a nakonec i daleko dražší z pohledu vývoje

Budu rád, pokud mě doplníte nebo v něčem opravíte...

31. března 2009

Spring MVC: GET kontroler

Dlouho jsem neuváděl žádný můj zdrojový kód, tak to dnes zkusím napravit. Spring MVC nabízí pro zpracování požadavku GET dva základní kontrolery:

  • ParameterizableViewController - jednoduchý kontroler, který pouze vyžaduje zadání cílového view, které se následně zobrazí.

  • BaseCommandController - kontroler, který pracuje s parametry requestu přes commandy. Tedy kontroler automaticky mapuje parametry requestu do atributů objektu (commandu), je možné využívat validace, bindery apod.

V každé aplikace resp. projektu se hodí mít nějaké své předky-kontrolery, které mohou zprvu být prázdné, ale vždy se časem ukáže, že je potřeba mít nějakou společnou funkcionalitu nebo společná data pro většinu nebo všechny kontrolery. My jsme se na projektu rozhodli mít dva předky-kontrolery, jeden pro práci s formuláři (zpracování POSTu) a jeden pro práci s GETem. A právě u GETu jsem narazil na to, že bych rád měl možnost výběru - jednou mi stačí si vytáhnout parametr přímo z requestu a jindy využiji command s validací. Takže z tohoto důvodu jsem udělal následující mix dvou výše uvedených kontrolerů. Pro úplnost ještě musím zmínit použití rozhraní IDataModelProvider, které slouží k předávání modelu resp. dat společných jak pro GET, tak pro POST kontrolery.


/**
* Zakladni implementace kontroleru pro zobrazovani stranek pres GET metodu, tj. zobrazeni
* JSP stranky, pripadne predani promennych na stranku.
*
* <p>Kontroler muze pracovat ve dvou "rezimech" - s commandem a bez nej.
* Pokud chceme pracovat s commandy a tedy mapovat parametry requestu do commandu, tak pak
* je vhodne v podtride implementovat metodu
* {@link #handle(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse, Object, org.springframework.validation.BindException)}
* a nastavit tridu commandu {@link #commandClass}.
*
* <p>Pokud nam staci pristup k parametrum requestu (bez commandu), tak pak je vhodne implementovat
* v podtride metodu {@link #handleRequestInternal(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)}.
* Toto chovani je defaultni.
*
* @see BaseFormController
*/
public class BaseGetController extends AbstractCommandController {
private static final Logger logger = Logger.getLogger(BaseGetController.class);

private IDataModelProvider dataModelProvider;
private String viewName;
private boolean supressBinding = false;
private boolean supressValidation = false;

protected void initApplicationContext() {
if (this.viewName == null) {
throw new IllegalArgumentException("Property 'viewName' is required");
}
}

/**
* Metoda resi, zda se bude pracovat s commandem (a tedy request parametry se budou
* napojovat na command) a nebo zda se bude pracovat bez commandu (a tedy je nutne pracovat samostatne
* primo s parametry requestu).
*
* <p><b>Tato metoda je vhodna k implementaci v podtridach, pokud nepracujeme s commandem
* a staci nam pristup k requestu.</b>
*/
protected ModelAndView handleRequestInternal(HttpServletRequest request,
HttpServletResponse response) throws Exception {
if (getCommandClass() == null) {
//pracujeme bez commandu
this.supressBinding = true;
this.supressValidation = true;
return this.handle(request, response, null, null);
}
else {
//pracujeme s commandem
return super.handleRequestInternal(request, response);
}
}

/**
* Metoda vklada spolecna data do vysledneho modelu.
*
* <p><b>Tato metoda je vhodna k implementaci v podtridach, pokud pracujeme s commandem</b>.
* Pokud neni {@link #commandClass} definovano, tak pak vstupni parametry <i>command</i> a <i>errors</i> jsou null.
*/
protected ModelAndView handle(HttpServletRequest request,
HttpServletResponse response,
Object command,
BindException errors) throws Exception {
ModelAndView mav = new ModelAndView(getViewName());

mav.addAllObjects(dataModelProvider.getModelData());

if (logger.isDebugEnabled()) {
logger.debug("BaseGetController returns: " + mav);
}

return mav;
}

protected boolean suppressBinding(HttpServletRequest request) {
return this.supressBinding || super.suppressBinding(request);
}

protected boolean suppressValidation(HttpServletRequest request, Object command) {
return this.supressValidation || super.suppressValidation(request, command);
}

public void setDataModelProvider(IDataModelProvider dataModelProvider) {
this.dataModelProvider = dataModelProvider;
}

/**
* Set the name of the view to delegate to.
*/
public void setViewName(String viewName) {
this.viewName = viewName;
}

/**
* Return the name of the view to delegate to.
*/
public String getViewName() {
return this.viewName;
}
}

29. prosince 2008

JSF: zkušenosti s NetAdvantage

O NetAdvantage komponentách jsem již několikrát psal (1, 2, 3) a rád bych napsal ještě jednou a tím to uzavřel. Již jsem se dříve snažil o nějaké zhodnocení a na to bych rád dnes navázal. Pokud se od té doby něco změnilo nebo jsou určité věci jinak než dříve, tak to nyní uvedu, jinak platí to co jsem již napsal.

S NetAdvantage komponentami jsme dělali přibližně půl roku, z toho tři měsíce celkem intenzivně. Projekt jsme zdárně stihli, takže (snad) všechny problémy, které jsme s komponentami měli, jsme dokázali nějak vyřešit. O použitých technologiích jsem psal v tomto příspěvku.

Ještě uvedu, že se budu vyjadřovat k verzi 8.2.20082.1003 - od té doby byly vydány dva nové hotfixy, takže něco může být lehce jinak.

Výhody

Seznam výhod nebudu rozšiřovat, stále platí co jsem již napsal. U podpory prohlížečů jsme narazili pouze na jeden problém a to v nastavení modality okénka (ig:dialogWindow) v IE 6 - v této verzi IE se nám prostě modální okénka nepodařilo rozchodit.

Obecně bych jako největší výhody NetAdvantage označil vzhled a AJAX. Komponenty vypadají hned "v základu" moc hezky, vše je možné skinovat. AJAX funguje bez problémů, člověk ho může používat, aniž by o něm něco věděl.

Nevýhody

Seznam nevýhod resp. nedostatků musím celkem rozšířit. Nejdříve bych ale doplnil informace uvedené v předchozím shrnutí:
  • dokumentace - úroveň uvedené dokumentace (JavaDoc a příručka programátora) jsou pořád na stejné úrovni, jen navíc přibyly nové stránky s ukázkami a příklady. Tyto stránky jsou moc pěkně udělány a navíc obsahují hodně vychytávek, které nikde jinde v dokumentaci uvedeny vůbec nejsou.

  • AJAX a MyFaces Orchestra spolu moc nefungují (neplatí) - toto již neplatí, chyba na straně Apache Orchestra (pozn. ona to úplně nebyla chyba, protože nikde není přesně popsáno jak má fungovat JSF a AJAX dohromady) byla opravena.

  • podpora pouze JSF 1.1 (neplatí) - jak jsem již psal, tak je možné již používat JSF 1.2.


Nyní bych rozšířil seznam nedostatků, na které jsme narazili v průběhu vývoje:
  • JSF chybové zprávy - v konfiguraci JSF jsme nastavili odkaz na vlastní properties soubor s chybovými hláškami. Správně se používají u standardních JSF komponent, ovšem s NetAdvantage komponentami (konkrétně např. ig:dateChoose) se pořád používají chybové hlášky z myfaces.jar.

  • nemožnost používat čisté HTML - i když samotné facelets umožňují libovolné používání "čistého" HTML včetně EL bez nějakých tagů (kdekoliv na stránce mohu použít #{data}), tak bohužel toto neplatí pro NetAdvantage komponenty. Uvnitř těchto komponent (my jsme to raději používali všude) je nutné EL volat pomocí h:outputText a čisté HTML tagy (konkrétné DIV) nahrazovat tagy z Tomahawku (t:div).

  • komponenta ig:dropDownList nefunguje s konvertery - o této chybě jsem již psal, zde uvádím znovu jen kvůli úplnosti

  • ig:link nemá onClick() - NetAdvantage náhrada za h:commandLink má navíc hlavně vestavěnou podporu pro AJAX, ale bohužel nemá metodu onClick. To je například problém, když máte tabulku s možností smazání libovolného řádku s tím, že vlastní smazání musí být ještě potvrzeno. Pokud chci AJAX, tak nemám možnost toto udělat, museli jsme použít normální h:commandLink a oželet v tomto případě AJAX.

  • ig:dateChooser ignoruje locale

  • problémy s ig:dialogWindow - ig:dialogWindow vytváří modální/nemodální okénko (ne pop-up okénko). Zde máme občas problémy s tím, že modalita není dodržena (při více aktivních okénkách na stránce) nebo si uživatel občas může všimnout problikávání při načítání stránky. Ale toto jsou pouze "kosmetické" věci, které bohužel uživatel připomínkuje nejčastěji.

  • předávání parametrů do komponent - vytvářeli jsme si Facelets komponenty pro různé tabulky (ig:gridView), protože jednou se tabulka použije v detailu, podruhé v editaci atd. Naše komponenty měly vždy alespoň jeden parametr a to dataSource pro načtení dat do tabulky. Bohužel předávání proměnné datového zdroje jako parametr naší Facelets komponenty nefungoval.

  • rekurzivní vytváření stromu - komponenta ig:tree umožňuje vytvářet stromy. Jednou z možností načtení dat do stromu je rekurzivní přístup, který nám bohužel nefungoval.

  • předávání objektu řádky tabulky pomocí f:setPropertyActionListener - NetAdvantage komponenta pro tabulku ig:gridView nabízí objekt #{DATA_ROW}, který představuje aktuální objekt pro určitou řádku tabulky. Bohužel není možné tento objekt nasetovat pomocí f:setPropertyActionListener.

  • ...


Závěr

Nakonec jsem vypsal jen ty nejdůležitější nedostatky, protože jich je mnohem více. Většina z nich je reportována výrobci jako chyba a většina z reportovaných chyb je označena statusem "In Development", tak snad budou někdy opravené.

Pokud nás během vývoje něco brzdilo, tak to byly NetAdvantage komponenty, protože vždy nějakou dobu trvalo, než jsme našli tu správnou cestičku. Musím hned ale dodat, že absolutní většinu všech nedostatků se nám podařilo vyřešit, obejít. Také je otázka, zda by to bylo výrazně jiné s jinými JSF komponentami? Pro nás to byl první větší projekt s JSF, takže jsme se učili spoustu věcí za běhu. Během vývoje jsme se několikrát ptali sami sebe, zda nezkusit jiné komponenty, ale dobře jsme udělali, že jsme vydrželi.

Závěrečná otázka asi bude "Použít či nepoužít"? Vzhledem k tomu, že již znám "cestičku", kudy jít při vývoji s NetAdvantage komponentami, tak bych se nebál je použít i na dalším projektu. Zvláště pokud by byla možnost do projektu zasahovat již v době návrhu, tak aby se již v této fázi eliminovaly "neprůjezdné cestičky". U nového projektu nevím. Pokud by to mělo být jen pro jeden projekt a nic dále, tak bych do toho nešel, ale pokud je to s vidinou toho, že to budete využívat i na dalších projektech, tak se pak ten čas navíc (u našeho projektu cca 20% času vývoje) celkem vrátí.

23. prosince 2008

BIRT reports vs. Jasper Reports

Je to dost častý problém - aplikace sbírá data a tyto data je potřeba nějak prezentovat formou reportů. Standardní výstupní formáty jsou HTML (na prohlížení) a PDF (na tisk).

Asi nejznámější řešení na vytváření reportů je Jasper Reports (pěkný článek o Jasper Reports vyšel na Java.cz).

My jsme pro náš projekt zvolili jiné řešení - Eclipse BIRT reports.

Rád bych nyní uvedl takové malé srovnání Jasper Reports a BIRT reports (s laskavým souhlasem mého kolegy Ondřeje Světlíka, který měl reporty na starosti).

Společné vlastnosti

  • umí lokalizaci textů
  • umí přistupovat k datům přímo přes JDBC, ale i jinými způsoby
  • umí grafy
  • umí všechny možné výstupní formáty - pdf, html, doc/rtf, xls a další

Jasper Reports

  • + výrazně menší runtime - cca 5M
  • + editor podporuje přímo práci se Spring beany
  • - nutnost kompilovat .jrxml na .jasper
  • - horší editor
  • - neumí tabulky, skládají se pouze buňky, takže něco jako změna šířky celého sloupce najednou (hlavička, obsah, patička) je nemyslitelné

BIRT reports

  • + lepší editor
  • + editor součástí Eclipse i standalone
  • + umí tabulky
  • + stylování pomocí CSS
  • + umožňuje skriptování v JavaScriptu
  • - obrovský runtime - cca 42M
  • - pokud má být datovým zdrojem Spring bean, musí se použít skriptovaný datový zdroj
  • - větší nároky na PermGen space, je nutné spouštět tomcat s -XX:MaxPermSize=256m (odzkoušená hodnota, zřejmě bude fungovat i menší, ale default 64m nestačí)


Já bych ještě doplnil mé osobní pocity. Velikost BIRT enginu (engine musí být součástí aplikace, generuje samotné reporty) je opravdu značná, v konečném důsledku asi 50MB. To už je celkem nárůst velikosti aplikace, i když se jedná o server.

Moc se mi líbil editor a obecně možnosti BIRTu samotného. Spoustě lidí může vadit přítomnost Javascriptu, ale já s ním problém nemám.

Trochu jsme měli problém s češtinou v PDF reportech, ale to jsme vyřešili nastavením kódování cp1250 v souboru fontsConfig_pdf.xml.

Propojení BIRT enginu a samotné aplikace je realizováno přes servlet - servlet zjistí potřebné informace o reportu (většinou z URL adresy) a předá je BIRT enginu. Ten pak už jen vygeneruje výstup, který se odešle klientovi.

Všechny definice reportů jsou v XML, takže z pohledu verzování nebyl žádný problém.

Jediný problém, který jsme zatím nevyřešili, je horizontální stránkování při výstupu do PDF. Toto BIRT ještě neumí.

S Jasper Reports jsem nikdy moc nedělal, ale asi už ani dělat nebudu. BIRT mě celkem zaujal...

Další odkazy

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í.

19. října 2008

Jaký webový framework používáte - výsledky

První minianketka je u konce s těmito výsledky:

  1. Spring MVC (36%)
  2. JSF (34%)
  3. Struts (16%)
  4. Něco jiného (14%)
  5. Samotné JSP a JSTL (8%)
  6. JBoss Seam (8%)
  7. Apache Wicket (6%)
  8. Spring Web Flow (6%)
  9. Tapestry (4%)

Hlasovalo celkem 61 lidí, takže se zrovna o velký vzorek lidí nejedná :(. Nechci z toho vyvozovat nějaké velké závěry, ale pár myšlenek si dovolím.

Pro mě osobně je Spring MVC a JSF volbou číslo jedna v současné době. Pokud potřebuji mít vše pod kontrolou, potřebuji mít rychlý web s velkou návštěvností, tak budu volit Spring MVC. Pokud si mohu dovolit JSF, tak volím JSF - tedy zejména pro intranetové aplikace, složité stránky a formuláře. Jedna volba nevylučuje druhou - JSF použiji třeba pro administrátorskou část aplikace, Spring MVC pro část prezentující data.

Struts mají silnou pozici z minulosti, takže na tom poběží pořád hodně projektů. Moc ale nepředpokládám, že by se toto řešení v nějaké větší míře používalo ještě dnes u nových projektů. Když už, tak aspoň Struts 2.

Tapestry jsou celkem staré (dnes je již beta verze páté verze) a ve své době měly několik revolučních věcí (např. provázání HTML a komponent přes speciální atribut, komponentový přístup), které ovšem v současné době jiné frameworky, které se nechaly inspirovat, řeší lépe (např. JSF Facelets, Apache Wicket). Musím se přiznat, že mě osobně nikdy moc Tapestry nezaujali.

Hodně by mě zajímalo, co se schovává pod "Něco jiného" u lidí, kteří tuto volbu zaškrtli. Možná Shale, WebWork, něco proprietárního, nevím...

26. září 2008

JSF s NetAdvantage - pokračování

Nedávno jsem psal o zkušenostech s komponentami NetAdvantage. Od té doby vyšla nová verze s celkem zásadními změnami, tak bych je rád uvedl.

Hlavní změna je ta, že jsou již podporovány JSF verze 1.2. Vzhledem k tomu, že vývoj naší aplikace je pořád spíše na začátku, tak jsme hned stáhli novou verzi a přešli na JSF 1.2. Přechod byl na 99% úspěšný, snad jen dvě chybky jsme jim tam našli.

Také jsme se rozhodli opustit klasické JSF a přejít na facelets. Zde těch problémů ze strany NetAdvantage komponent je více, některé celkem zásadní, např. nemožnost použití WebChart komponent. Více na stránkách známých omezení (1, 2, 3).

Problém s konvertery, o kterém jsem psal minule ("komponenta ig:dropDownList nefunguje s konvertery"), se nakonec ukázal jako ještě větší a obecnější, který zasahuje přes více komponent, např. dateChooser.



Z mojí mini ankety "Jaký webový framework používáte?" zatím vyplývá, že se JSF používají celkem dost. Mě by hodně zajímalo, zda využíváte pouze open-source knihovny nebo zda máte nějakou zkušenost s jinými komerčními JSF knihovnami?

7. září 2008

JSF s NetAdvantage

Pro poslední projekt jsme se rozhodli použít JSF. Jedná se o intranetovou aplikaci s velkým důrazem na vzhled a funkčnost grafického rozhraní, takže jsme si řekli, že by to nemuselo být špatné to udělat pomocí JSF. Moc zkušeností s JSF jsme v týmu neměli, takže jsme se rozhodli použít nějakou komerční JSF distribuci, zejména kvůli podpoře. Nakonec jsme vybrali NetAdvantage for JSF (máme verzi 2008 Volume 1) od firmy Infragistics.

S NetAdvantage pracujeme celkem intenzivně dva měsíce, což už je doba na nějaké to shrnutí. Jako každé řešení, tak i toto má svoje výhody a nevýhody.

Výhody

  • podpora AJAXu - programátor nemusí nic vědět o AJAXu a může bez problémů dělat AJAXové aplikace. AJAXové chování lze ovlivnit jednak pomocí atributů jednotlivých komponent resp. tagů a nebo pomocí Java API z managed beanů. Už žádný Javascript, vše funguje úplně parádně samo.

  • kvalitní podpora - komponenty NetAdvantage se kupují na dobu jednoho roku a je možné si vybrat různé úrovně podpory. My máme tu základní úroveň, což znamená, že můžeme psát na fórum a nebo přímo jim s případnými problémy. Odezvy na naše dotazy jsou hodně dobré, řekněme v průměru do jednoho dne. Většinou odpovídají ještě v rámci dne (řekl bych, že někteří členové týmu jsou z východní Evropy, takže mají stejnou pracovní dobu jako my).

  • web grid (tabulka) - tabulku používáme velice často, a proto když jsme vybírali mezi různými distribucemi, tak jsme právě na tabulky dávali velký důraz. Tabulka od NetAdvantage toho umí opravdu hodně, to se nám již potvrdilo.

  • grafy - ty jsme zatím nepoužily, ale stačí se podívat do ukázek a člověk uvidí opravdu hodně velké množství všech různých typů grafů. Stačí si jen vybrat...

  • podpora Apache MyFaces a Sun RI JSF - NetAdvantage fungují nad oběma základníma implementacemi JSF. My jsme nejdříve používali Sunovskou verzi a pak jsme přešli na MyFaces verzi. Důvod? Zatím spíše subjektivní - MyFaces více žije, rychleji se opravují případné problémy a hlavně bychom rádi postupně začali využívat další komponenty (Tomahawk, Tobago, ...) od MyFaces.

  • podpora prohlížečů - vzhled a chování komponent je odladěné pro všechny nejpoužívanější prohlížeče.

  • velké množství skinů - NetAdvantage nabízí velké množství (cca 15) barevných skinů, takže není až tak velký problém s návrhem grafického rozhraní aplikace dle svých požadavků.

  • hotfixy - každý software má své chyby a nejinak je tomu u NetAdvantage. V průměru každý měsíc až dva měsíce vychází nový hotfix, který opravuje reportované chyby. Toto bych řekl, že celkem funguje.


Nevýhody

  • dokumentace - celkově mi dokumentace nepřijde moc kvalitní. JavaDoc sice existuje, ale skoro bez popisu. Zbylá dokumentace obsahuje pouze základní informace a některé věci tam ani nejsou, např. komponenta ig:link. Součástí instalace jsou i ukázky včetně zdrojových kódů, takže pro první seznámení to stačí. Horší kvalita dokumentace je vyvážena podporou ze strany výrobce komponent. Abych byl spravedlivý, tak zde musím uvést, že když jsem začínal s NetAdvantage, tak jsem začínal i s JSF, takže jsem dost často neřešil ani tak problémy s NetAdvantage jako spíše s JSF.

  • AJAX a MyFaces Orchestra spolu moc nefungují - používám MyFaces Orchestra kvůli konverzacím (viz minulý článek) a jak se ukázalo, tak neexistuje žádný standard pro implementaci AJAXu v JSF komponentách. Zatím to tedy dohromady moc nefunguje (některá AJAXová volání nesprávně ukončují konverzaci), snad se to nějak vyřeší (1, 2, 3)

  • podpora pouze JSF 1.1 - v současné verzi komponent NetAdvantage je podporována pouze JSF verze 1.1. JSF 1.2 budou podporovány od další verze.

  • komponenta ig:dropDownList nefunguje s konvertery - komponenta ig:dropDownList je náhradou za standardní JSF komponentu h:selectOneMenu, ovšem s podporou AJAXu. Bohužel ig:dropDownList nefunguje správně s konvertery, takže se s tím úplně dobře nepracuje.


Ještě toho budeme hodně zkoušet, takže pravděpodobně tento článek bude mít své pokračování. Zatím jsme třeba ještě nezapojili jiné komponenty třetích stran než od NetAdvantage, takže jsem zvědavý na vzájemnou kompatibilitu.

Další zajímavé zdroje:

25. srpna 2008

JSF - FacesTrace a MyFaces Orchestra

Teprve nedávno jsem začal používat JSF a musím se přiznat, že se v tom pořád tak nějak plácám. Jsem zvyklý, že při programování mám vždy vše pod kontrolou, ale tady z toho takový pocit nemám. Ale toto téma si nechám až na nějaký další článek.

V tomto článku bych chtěl zmínit dvě knihovny, které mi celkem zpříjemnily mojí práci s JSF.

FacesTrace

Pokud nastane nějaký problém s JSF, tak někdy je dost těžké vůbec zjistit příčinu problému - skoro žádné logování, skoro žádné ladící informace. Tato knihovna v tomto ohledu aspoň trochu pomůže.

Použití je velice jednoduché - přidá se knihovna k aplikaci a na stránce určené k ladění se použije tag <ft:trace />. Někdy je ještě nutné přidat mapování do web.xml.
Ukázku poskytnutých informací lze vidět zde.

MyFaces Orchestra

Při práci s JSF dost často nestačí ukládat proměnné jen do rozsahu requestu (pokud tedy chceme zachovat "rozumnou eleganci" vývoje s JSF). Potom musíme sáhnout po session, což není ideální, minimálně z pohledu nároků na paměť a škálovatelnosti (další důvody jsou uvedeny zde).
MyFaces Orchestra nabízí něco mezi - konverzaci. MyFaces Orchestra vyžaduje přítomnost Springu, protože využívá možnosti Springu si definovat vlastní rozsah (scope) pro uložení beanů resp. JSF managed beanů. Je možné využívát dva typy konverzací:
  • automatická - konverzace se automaticky vytvoří při přechodu na bean, který je definován pro rozsah konverzace. Při přechodu na bean s jiným rozsahem (request, session) se konverzace automaticky ukončuje.

  • manuální - řízení začátku a konce konverzace je plně na programátorovi pomocí dostupného API.

Kromě toho knihovna ještě nabízí "persistence in conversation". Tedy něco jako "session in view", ale zde pouze v rozsahu konverzací.

Knihovna je nezávislá na implementaci JSF API, tedy funguje nejen nad Apache MyFaces, tak i nad Sun RI. Knihovny jsem zkoušel s JSF 1.1.


Pokud máte nějaké další tipy na knihovny, které pomohou s vývojem v JSF, tak sem s nimi prosím :).

17. dubna 2008

Porovnání webových frameworků

Včera jsem zkouknul zajímavou prezentaci, kde se autor snaží na základě svých zkušeností a z pohledu různých kritérií porovnat Java webové frameworky (JSF, Spring MVC, Stripes, Struts 2, Tapestry, Wicket).
Pokud si chce člověk udělat takový první názor a nechce si všechny ty frameworky zkoušet, tak mi ta prezentace přijde super.

2. března 2008

Proč nemám rád Seam

V poslední době se hodně hovoří o JBoss Seamu - píší se o něm články (1, 2, 3), přednáší se o něm, u nás v práci se vedou diskuze, zda ho použít nebo ne. Mě už to prostě nedá, abych zapřemýšlel veřejně, protože bych moc rád moje názory zkonzultoval s okolním světem.

Ještě než se pustím do "přemýšlení", tak musím poznamenat, že jsem hodně ovlivněný Springem - mám tu technologii rád, nikdy mě nezklamala, ztotožňuji se s názory lidí ze SpringSource. Mám také rád Javu, protože mám možnost plné kontroly nad aplikací, když chci napsat výkonnou, škálovatelnou a robustní aplikaci.
Také musím napsat, že nemám žádnou větší zkušenost se Seamem, pouze jsem si zkoušel a procházel nějaká dema.

Co se mi na Seamu líbí?

  • výborně integruje (a opravuje) technologii JSF a pokud dnes někdo chce používat JSF, tak asi určitě se Seamem.

  • Seam framework integruje spoustu technologií dohromady v jeden kompaktní celek.

  • Seam považuji nejsilnější v prezentační vrstvě, hlavně se mi líbí možnost využití a integrace AJAXových komponent.

  • Nemůžu nezmínit rychlost vývoje, potažmo náklady na vývoj aplikace.

Co se mi na Seamu nelíbí?

  • velice mi jsou blízká "čistá", flexibilní řešení, protože člověk nikdy neví (lépe řečeno zákazník nikdy neví). Z tohoto pohledu se mi Seam moc nelíbí - z vlastní zkušenosti vím, že hodně často je potřeba ještě jedna vrstva (Facade) mezi kontrolerem a aplikační vrstvou. Dnes je in, že vše musí být POJO, ale pokud POJO má na sebe navěšeno spoustu anotací, které mi zabraňují v testování, které mě vážou k nějakému řešení, tak už to není POJO.

  • Všechno kromě snad prezentační vrstvy (ale i zde by se dalo spekulovat) jde udělat stejně dobře nebo lépe pomocí Springu. Mám na mysli zejména možnosti integrace s dalším knihovnami, možnosti konfigurace, možnosti testovatelnosti apod.

  • Spring security (dříve Acegi framework) považuji za nejlepší open-source řešení pro zajištění bezpečnosti aplikací. Seam pěkně zapojil Drools, ale i tak se to nedá srovnávat, hlavně co se týče flexibility a možností.

  • Vše je konfigurováno pomocí anotací. Někdo je má rád, někdo ne. Já jak kdy, takže mi tu chybí možnost volby. Např. konfigurace scheduleru přes anotace v Seamu mi přijde celkem hrozná.

  • Kompaktnost řešení je negativně vyvážena omezenou možností použití řešení třetích stran.

Co říci závěrem

V žádném případě nemohu říci, že Seam je špatný framework, protože to není pravda. Seam udělal resp. udělá velkou službu Java světu, protože dokáže přitáhnout lidi, kteří chtějí dělat malé až středně velké webové aplikace bez nějaké větší aplikační logiky v pozadí, kteří ale nechtějí nebo mají strach se prokousávat tolika technologiemi, které je potřeba pochopit a naučit se.

Já ale (snad) už začátečník v Javě nejsem, potřebné technologie znám, nerad vytvářím GUI, spíše mě zajímá pozadí aplikace, píši malé, středně velké až velké aplikace, které nepracují pouze s databází, které mají mnohdy složitou aplikační logiku, které mají být výkonné, robustní... A proto tedy nemám rád Seam.

20. října 2007

ImageUploader - komponenta pro upload souborů

Na posledním projektu jsme celkem dost intenzivně používali komponentu ImageUploader od firmy Aurigma. Tuto nebo jinou komponentu jsme museli použít, protože zákazník měl následující požadavky:

  • elegantní způsob výběru dokumentů (textových i obrazových)

  • možnost náhledů pro obrazové dokumenty

Také je vhodné dodat, že předchůdce námi vyvíjené aplikace byla desktopová aplikace a spoustu uživatelů nebylo možné přesvědčit, že webová aplikace se chová jinak než standardní Windows aplikace.



S komponentou jsme pracovali přibližně půl roku. Komponentu jsme nevyužívali jen pro jednoduché odesílání souborů, ale potřebovali jsme odeslat dalších cca 30 položek formuláře. Některé věci šli celkem bez problémů, jiné bylo potřeba různými způsoby obcházet a myslím, že s výsledkem je i zákazník spokojený.
Než abych to složitě popisoval, tak nyní shrnu výhody a nevýhody, které tato komponenta z našeho pohledu má.

Výhody
  • komponenta je dostupná jak pro IE (ActiveX verze), tak i pro ostatní prohlížeče (Java applet verze)

  • kvalitní dokumentace včetně kvalitního online dema

  • celkem kvalitní podpora, např. forum

  • chování komponenty lze upravit konfigurací velkého množství parametrů, vše se ovládá pomoci JavaScriptu

  • komponenta neslouží jen k výběru souborů a jejich odeslání, ale umožňuje například vytváření náhledů, získávání informací z EXIF, přidání vodoznaku atd. Přehled vlastností je možné si prohlédnout zde.

  • i cena mi přijde rozumná. Za dualní verzi (ActiveX a Applet) s vazbou na doménové jméno serveru je cena $299.


Nevýhody
  • možnosti a chování obou verzí (ActiveX, Applet) nejsou totožné. Není to jen rozdíl (není ale jinak výrazný) v chování komponenty z pohledu uživatelského ovládání, ale hlavně rozdílu z pohledu funkcionality - odlišná podpora formátů obrázků (např. TIFF obrázky), jiné možnosti získání informací z EXIF, odlišný přístup pro získání data vzniku dokumentu. Toto je zřejmě dáno rozdíly v použitých jazycích pro vývoj těchto komponent (Java vs. C#).

  • slabá integrace s komponentou Thumbnail. Tato komponenta je dodávaná spolu s ImageUploader a slouží pro zobrazování náhledů vybraných dokumentů. Tato integrace ale nefunguje úplně 100% - je k tomu potřeba celkem dost JavaScript kódu, chování se liší pro obě verze komponenty a pořád se nám to nepodařilo dotáhnout do takové podoby, jakou by jsme chtěli.

  • zatímco ActiveX komponenta resp. IE neměly s testovacími certifikáty (tj. certifikáty podepsanými naší interní autoritou) žádné problémy, u Java verze to bylo horší. Pokud jsou ale certifikáty pro HTTPS podepsané nějakou známou autoritou, tak také není žádný problém.


I přes nějaké ty nevýhody jsem byl spokojený a pokud bude potřeba, tak tuto komponentu použiji i v dalších projektech.