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í.
Příspěvky
9 komentářů:
"JSF je J2EE standard": Who cares? Na servisnej a datovej vrstve tiez bezne pouzivame Spring Framework a Hibernate ktore niesu J2EE standardom a nikomu to nevadi. Tak preco by nam to zrazu malo vadit na prezentacnej vrstve?
"vzhled prodává": Ak chcete vidiet skutocne revolucne riesenie skinovatelnych komponent tak sa pozrite napr. sem www.scalenine.com . V porovnani s tym JSF skinovatelnost posobi skor ako chudobny pribuzny.
ad standard: Na posledním projektu jsem chtěl použít cokoliv jiného než JSF - nikdy jsem s nimi nedělal a měl jsem k nim prostě nedůvěru. Chtěl jsem Spring MVC (to znám) nebo Apache Wicket (rád bych se naučil). Nic neprošlo. Jedním z důvodů bylo, že jsme si na to potřebovali najmout externí síly a vedení si myslelo, že když to je standard, tak to bude lepší. Ostatní technologie na projektu zvládáme sami, takže na to jsme nikoho nehledali.
Navíc, dle mého názoru, Spring má v open source světě výjimečné postavení - J2EE standard to oficiálně není, ale rozšíření je takové, že to tak skoro brát lze. Podobné i s Hibernatem, akorát tam už lze říci, že je JPA.
ad vzhled: to vypadá opravu suprově, k tomu není co dodat.
Musim trochu oponovat. Velkym problemom pre nas pri JSF technologii bol prave vzhlad komponent. Ten si nevybera programator ale zakaznik vam posle krasne screenshoty a robte. Samozrejme, ze ich vytvaral designer, ktory o JSF nemal ani paru. Je pravda, ze ich komponenty su pekne (hlavne MyFaces) ale zakaznika to proste nezaujima a su vhodne iba na prezentacne ucely. Prisposobovanie tychto komponent na poziadavky zakaznika je prakticky nemozne. Jedinym riesenim bolo vybrat jednoduchsie komponenty od tomahawku a prepracovat ich (skor by som napisal ze hacknut) tak aby robili to co chceme. Toto rozhodne nieje dobre riesenie ale bohuzial ine nepoznam.
Tak jak to píšete vy, tak to je opravdu problém.
My jsme se to od začátku snažili udělat obráceně a povedlo se (snad to tak půjde vždy) - design jsme dělali sami plně s vědomím možností NetAdvantage komponent. Barevně jsme si úplně nesedli s již existujícími skiny, ale nebyl zase velký problém to upravit na barvy zákazníka.
Ad rychlost vývoje) To je ale příšerně subjektivní názor, navíc pokud jste jiné technologii nedali šanci. Když si jako své první auto vyberete škodovku 120, pak vám bude také připadat jako rychlá, dokud nezkusíte něco jiného a nebo vás nepřejede něco jiného.
Navíc na JSF je nutno vyzvednout další nevýhodu, kterou Wicket a nebo Tapestry nemá. Tj. šablony nemůže dělat web-designér, protože s HTML nemají nic společného, musí je dělat programátor.
ad rychlost: ano, je to velice subjektivní. Jen jsem měl pocit, že to proste odsejpalo :).
ad šablony: Wicket i Tapestry jsou určitě dále, to žádná, ale myslím, že i pomocí Facelets je to možné rozdělit - atribut jsfc. Mohu tedy psát normální HTML a pomocí atributu jsfc určuji výsledný JSF element. Něco hodně podobného jsem viděl i v Tapestry.
Příklad: <input type="text" jsfc="h:inputText" value="#{hello.world}" />.
Váš vývoj je úspešný nie kvôli JSF ale vďaka komerčným knižniciam. Tie nie sú ani štandardné, ani nie je zaručený ich dlhodobý vývoj (a neviem či máte k dispozícii zdrojové kódy).
Rovnako si ale môžem kúpiť iné knižnice, prepojiť ich napríklad so Sprites a moje aplikácie budú tiež štandardné, krásne a vývoj bude podľa mňa rýchlejší ako s použitím JSF.
To Petr:
> Chtěl jsem Spring MVC (to znám) nebo Apache Wicket (rád bych se naučil). Nic neprošlo. Jedním z důvodů bylo to že vedení si myslelo, že když je JSF standard, tak že to bude lepší.
Tu si udrel klinec po hlavicke. Jednym z marginalnych problemov vacsiny projektov je to ze o vybere technologii rozhoduju ludia ktori tomu najmenej rozumeju.
Jedine co sa mne osobne v takomto pripade osvedcilo je, na zaciatku projektu, vytvorit niekolko prototypov s pouzitim alternativnych technologii a priamo porovnat vyvojovy cas a objem vysledneho kodu s pouzitim jednotlivych technologii. Potom je uz relativne jednoduche vycislit ze s pouzitim frameworku X oproti Y budeme schopny usetrit tolko a tolko mandays co nam v konecnom dosledku umozni usetrit tolko a tolko EUR/CZK. Toto je jazyk ktoremu manazeri rozumeju a asi jedine riesenie ako ich presvedcit o vyhodnosti/nevyhodnosti urcitej technologie.
To Petr:
> Spring má v open source světě výjimečné postavení - J2EE standard to oficiálně není, ale rozšíření je takové, že to tak skoro brát lze.
Ano to je pravda, ale nebolo to stale tak. Staci si spomenut na diskusie okolo Spring Frameworku spred niekolkych rokov, kde sa bezne pouzivali argumenty typu:
"Why would anybody use that pet project called Spring? EJB 2.x is the only way to go because it's J2EE standard!"
A tlacilo sa to ludom do hlavy stale dookola a dookola, pretoze velke korporacie ako Sun, Oracle, IBM, JBoss maju dostatok financii na marketingove pretlacanie svojich technologii.
Keby neexistovali jednotlivci ktori sa nebali experimentovat so Spring Frameworkom, aj napriek tomu ze nieje J2EE standardom, tak by sme dodnes pouzivali EJB 2.x a travili v praci minimalne 30 hodin denne.
Podobne to bolo aj s Hibernate vs. Entity EJB 2.x. Staci si vyhladad niektoru s historickych diskuzii kde spolu ohnivo diskutuju zastancovia a odporcovia Hibernate a Entity EJB 2.x pristupu.
Okomentovat