Opět jsem narazil na velmi zajímavý blog, který porovnává složitost vytváření komponent v JSF 2.0 a Tapestry 5 ("Simple" JSF 2.0 Component vs. Tapetry).
Samotného mě takové porovnání již dlouho zajímalo, protože jsem se o JSF přestal zajímat někdy okolo verze 1.0, přišlo mi zkrátka moc složité a komplikované. Navíc mělo veliké problémy na úrovni integrace s JSP (to už je snad minulost). Takže pokud se někdo nechce koukat na originál, pak vězte, že napsat komponentu v JSF, která vypíše text na žlutém pozadí je realizováno následující komponentou:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:composite="http://java.sun.com/jsf/composite">
<head>
<title>This will not be present in rendered output</title>
</head>
<body>
<composite:interface name="yellowOut"
displayName="Very Basic Output Component"
preferred="true"
expert="false"
shortDescription="A basic example">
<composite:attribute name="value" required="false"/>
</composite:interface>
<composite:implementation>
<h:outputText value="#{compositeComponent.attrs.value}" style="background-color: yellow"/>
</composite:implementation>
</body>
</html>public class Out {
@Property
@Parameter(defaultPrefix = BindingConstants.LITERAL)
private String value;
}
<span style="background-color: yellow">${value}</span>
Příspěvky
10 komentářů:
Pro mensi (soukrome) projekty mozna, ale Tapestry ma bohuzel tu neblahou vlastnost ze mezi verzi 3 a 4 se udalo pomerne dost zmen a to uz vubec nemluvim o verzi 5, ktera je v podstate o zahozeni projektu a napsani znovu... Pro JSF mluvi to, ze je to industry standard a vyviji se pomaleji ;)
Osobně jsem také zastánce lehčích frameworků na frontendu. Vždycky když jsem dělal něco s JSF (MyFaces, Oracle ADF Faces) tak jsem se dost nadřel. Se Seamem je to možná jiné, ale ten mi připadá jako ještě větší tank. Připadá se mi, že ve zmíněných implementacích JSF chybí plno takových drobností, které je člověk zvyklý dostat out of the box (např. podpora uploadu) nebo naopak vás nemile překvapí problematické řešení takových jednoduchostí jako je práce s request parametry při GETu.
Tzn. většinou si člověk musel dopsat X PhaseListenerů a dostáhnout X dalších doprovodných technologií, aby vůbec byl schopný projekt rozumně realizovat (možná proto, že jsme nikdy neřešili komplexní informační systém, jsem měl na konci vždycky pocit, že se nám to moc nevyplatilo).
Komponentový systém je zásadní z hlediska reusovatelnosti komponent, ale psaní vlastních (byť jednoduchých - viz. příklad) není rozhodně triviální a použití externích (např. z Tomahawku) je v reálu taky docela legrace. Bez zdrojových kódů bych byl docela v koncích a po dlouhém debugování v cizím kódu, kdy se člověk snaží zjistit, proč nefunguje to, co by podle selského rozumu fungovat mělo, si člověk taky ve výsledku nepřipadá moc produktivní.
Když to srovnám třeba s naprosto jednoduchými Stripesy, je to nebe a dudy. Stripsy stáhnete, za půl dne v nich už programujete a pokud si nevymýšlíte ptákoviny stačí vám bohatě základ, bez hackování do základního životního cyklu. Ve výsledku máte na konci pocit větší kontroly a skoro bych řekl, že na jednodušších a středně složitých projektech budete s prací rychleji hotovi.
> Pro JSF mluvi to, ze je to industry standard
To ze je nieco onalepkovane ako oficialny J2EE standard este automaticky nezarucuje aj kvalitu (ono to v skutocnosti byva skor naopak). Staci si napriklad spomenut ako neslavne dopadol J2EE standard EJB2 v suboji s open-source Spring Frameworkom.
S Tapestry 5 osobne pracujem nieco vyse roka a prechod z JSF urcite nelutujem. Tapestry 5 ma neporovnatelne jednoduchsi komponentovy model s ktorym je vyvoj novych komponent doslova zabavou, revolucny IOC container ktory vam umoznuje velmi pohodlne prepisat ci pozmenit ktorukolvek cast implementacie (a to vsetko bez jedineho riadku XML), automaticke reloadovanie zmien v kode takze restartovanie aplikacne serveru resp. redeployovanie aplikacie po kazdej zmene je davnou minulostou, ak urobim v kode nejaku chybu tak Tapestry mi presne povie v ktorom subore a na ktorom riadku som tu chybu urobil takze nemusim stravit niekolko hodin nezmyselnym debugovanim, ma taktiez vybornu skalovatelnost a performance, ponuka neporovnatelne vyssiu produktivitu vyvoja, atd. atd.
Tapestry 5 je framework ktory ma po dlhom case presvedcil ze Java na prezentacnej vrstve ma predsa len zmysel a ze vyvoj webovych aplikacii v Jave moze byt jednoduchy a zabavny.
Naopak pri praci s JSF som mal vzdy skor pocit permanentnej frustracie a castokrat som uvazoval ci by predsa len nebolo lepsie opustit Java platformu a skusit nieco ine. Obcas mi tiez napadlo ze JSF snad museli navrhovat nejaki .Net agenti aby Java vyvojarom znechutili ich pracu a lahsie ich pretiahli na ich stranu.
Ako pozeram, tak lubovolny framework to ma jednoduchsie ako JSF 2.0.
Pre porovnanie tiez Wicket, kde je to velmi podobne. Jedna trieda dediaca od Labelu (prazdna trieda s ,,oddedenymi konstruktormi") a jednej HTML sablony s jednym elementom.
Honza Novotný: Jen bych si dovolil upřesnit, že Stripes není primárně komponentní, přičemž to neubírá na kvalitě systému layoutů a "komponent".
Co se týče Tapestry, tak verze 5 je pro mě osobně něco úchvatného. pracoval (resp. snažil se pracovat) s Tapestry 4, ale systém abstraktních tříd byla nepoužitelná obludnost.
Chapu, ze to srovnavas s tim, ze dopredu vis, kdo ma vyhrat.
XML hlavicka je zkopirovana (sablona). Navic, kdyz se do ni podivas, dva namespacy nejsou pouzity, takze jdou vyhodit.
Title s obsahem "This will not be present in rendered output" je tam proc? Aby to bylo delsi?
Je to XML, takze JE to ukecanejsi. Ovsem po vyhozeni nepotrebnych casti je to skoro stejne dlouhe. Taky hadam, ze k tomu bude taky nejaka napoveda diky schematu. Tapestry trida je zjevne neco, co si Tapestry samo parsuje (hadam, neznam!), takze syntakticke chyby se objevi az za behu.
Mozna kecam (vlastni komponenty jsem nikdy nepsal), jen mi to nepripada jako fer srovnani; doufam, ze mi to promines :-)
To Pepcza: jasně - vím že Stripes nejsou komponentové - spíš jsem je zmiňoval kvůli jednoduchosti.
Podle mého názoru komponentové framerowky jsou obecně těžkopádnější oproti request based frameworkům. Tím spíš by se měly zabývat jednoduchostí vytváření nových komponent - protože to je jejich core business.
Ale rozjel se nám tu pěkný flame ;-)
aubi> Nejsem znalec JSF ale ten příklad je zkopírován z blogu Jima Driscolla, kde se jasně prezentuje jak je to jednoduché a trivialní (doslova: No Java code is required for this very simple example).
Nejde jenom o počet řádků, ale také o přehlednost a přiznám se, že Tapestry přístupu rozumím, kdežto JSF mi
přijde nějak moc komplikované.
Jinak jsem moc rád, že se najdou i lidé, kteři, stejně jako já, věří přístupu Tapestry.
Z toho co vím, tak stripes jsou hodně vylepšené struts (nebo lépe jsou duchem podobné struts). Struts používáme ještě dneska, před 5 lety to byla klasika. Ale hrozně mi vadí ten neobjektový přístup, spíš funkcionální.
Nejsem znalcem Tapestry, ale vytvareni komponent v JSF2.0 mi neprijde slozite. Tento priklad je trochu tendencni (mozna, ze si autor puvodniho clanku zacal :)), jde o primitivni komponentu (vlastne jen o prebarveny outputText z JSFek), kvuli ktere se ale musi do XMLka doplnit spousta namespacu, tagu (interface a implementation) a nepovinnych atributu, ktere ve finale slouzi pouze jako napoveda (zde nevhodne pouzite pouze pro ukazkove ucely, napr. description). Mnohem vetsi komponenta by mela te omacky priblizne stejne mnozstvi. Navic u tapestry se musi definovat dve veci, u prikladu z JSF je vse na jednom miste.
Rekl bych, ze je to jen hodne popisne. Vzhledem k tomu, ze vetsinu za mne vygeneruje IDE, nerekl bych, ze je to slozite. Argument, ze je mi to jasne na prvni pohled, nepouziju, protoze jsem zvykly delat JSFka a znam Facelets (a jak tak na to koukam, tak tohle je presne Faceletovske reseni :))
Ale kazdemu co jeho jest, JSFka jsou a byly vzdycky velka obluda a kazdy framework ma sva pro a proti.
sm4rtus
Okomentovat