In het geval van deze JSR is het zeker niet alleen Sun. Ook organisaties als bijvoorbeeld Apache of Google hebben aardig wat in de melk te brokkelen. Je zou kunnen zeggen dat democratie niet werkt in het geval van Java EE en dat er een monopolist achter moet zitten om een product te maken en die als de facto standaard neer te zetten. In het geval van Java EE 5 zijn er heel veel partijen die er belang bij hebben, en die willen allemaal dat hun wensen in de spec komen. Het zelfde geldt voor open source projecten die te veel contributies van verschillende developpers toe staan. Die worden ook bloated en log.
Aan de andere kant kun je je afvragen of democratie en openheid je die prijs waard is. Voor somiggen is dat zo en voor somiggen niet. Er zijn mensen die bloat gewoon kunnen negeren. Of iets nu 10 of 200Mb op mijn server inneemt kan mij persoonlijk weinig schelen als ik er een gigabit verbinding naar toe heb en er 16GB geheugen + 500GB disks inzitten. Dat er 2048 packges in een product zitten terwijl ik maar van 4 classes consume, tsja... zolang die 4 classes doen wat ik wil zal ik er niet van wakker liggen.
Je kunt het een beetje vergelijken met wonen in de stad. Er zijn mensen die gek worden van alle drukte om zich heen, maar er zijn ook mensen die in alle drukte gewoon rustig op een bankje gaan zitten, zich helemaal in een boek verliezen en de drukte niet eens zien of horen.
Natuurlijk wil je soms wel eens de wens hebben om dingen ANDERS te willen. Als expert kun je dit eisen. Voor veel beginners/gemiddelden is te veel vrijheid niet goed. Die misbruiken het en gaan rare dingen doen. Neem nu een plain JSP pagina. The sky is werkelijk the limit. Je kunt er op doen wat je wilt; SQL query'tje draaien midden op de pagina? Het kan! Vervolgens er met een loop over iterreren en allemaal business logic uitvoeren? Niemand houd je tegen. Beginners misbruiken deze vrijheid dan ook vaak gruwelijk. Als eindverandwoordelijke voor code mag jij dan later de brokken opruimen. Vandaar dat ik de beginnende mensen dus ook liever met een techniek laat werken die ze lekker dwingt volgens vaste paden te wandelen.
Na verloop van tijd zul je dan zien dat die dwang je opeens meer vrijheid geeft, want je kunt alles wat je hebt gemaakt veel makkelijker aan elkaar clicken en mixen; alles werkt volgens standaard patronen. Miljoenen mensen schrijven elke keer weer dezelfde regels aan code op een JSP/PHP pagina. Dingen als:
Java:
1
2
3
4
5
6
7
8
9
10
11
| <% String param = request.getParameter( "cust_id" );
int intParam = -1;
if ( param != null && param.lenght() > 0 ) {
try {
intParam = Integer.parseInt(param);
}
catch (NumberformatException) { /* do stuff */ }
}
obj.doBussiness(intParam);
// etc
%> |
Dergelijke code sequences (in deze vorm of een gelijkwaardige) geven uitdrukking aan de ultieme vrijheid. Maar je -moet- het wel telkens overnieuw schrijven. De vrijheid wordt dus een dwang. In JSF daarentegen defineer je 1 maal een zogenaamde converter. Die hang je aan een field. En klaar. Je kunt dat ding 1000.000 keer her-gebruiken, extenden, aanpassen etc. (en de meest voor de hand liggende zitten al standaard in JSF)
[edit2]
Verder heeft JSF uiteraard wel goeie features, maar je moet niet vergeten dat er ook veel andere pagebased/component based frameworks zijn: Tapestry, Wicket, Click en nog wel een paar. Ik zou wel eens mensen willen horen die bv met JSF en met Wicket of Tapestry hebben gewerkt en wat ze het meest prettige vinden werken.
Nou heb ik weinig ervaring met Wicket of Tapestry, maar wat me opviel is dat het er in de eerste instantie redelijk gelijkwaardig uitziet. Je hebt weer componenten, je hebt weer MVC etc. In Tapestry lijkt het allemaal net gewoon HTML, wat weer scheelt voor sommige.
Echter waar JSF zeker enorm krachtig is, is in de uitbreidbaarheid. Property-resolvers, variable-resolvers, view-handlers, state-managers, phase-listeners... voor bijna ALLES wat JSF doet kun je je eigen implementatie via een soort plug-in mechanisme aan toevoegen. De handlers zijn werkelijk enorm krachtig. Je kunt ermee het standaard gedrag van JSF beinvloeden of totaal veranderen. Beinvloeden gaat via een decorater pattern. Voeg een handler toe in een XML config file en jouw handler krijg automatisch een reference naar de vorige handler. Zo kun je 1 bepaald aspect beinvloeden en de rest door laten gaan naar de standaard handler.
Een leuk voorbeeld is deze post, laatste bericht:
http://saloon.javaranch.c...b=get_topic&f=82&t=001178
Een beetje nare eigenschap /BUG in JSF, en met een paar regels code vertel je JSF opeens dat ie op een hele andere manier (jouw manier dus) de view tree moet gaan restoren; simpelweg omdat je in staat wordt gesteld het essentiele stukje code dat dit normaal doet te decoraten.
Een andere punt waar je een enorm grote flexibiliteit krijgt is in het fases/life-cycle model. In eerste instantie denk je: "waarom zo'n life-cycle". Maar dan zie je opeens dat je op relatief simpele wijze erg leuke dingen kunt doen. Dmv een life-cycle phase-listener kun een custom component maken die als enigste component op een pagina op iets reageert. Je laat bv een component aan de hand van een token iets naar de response schrijven in de process decode phase. Als je dit conditioneel doet zal nog geen enkel andere component iets naar de response geschreven hebben (dat doe je normaal pas enkele phases later). Vervolgens kun je met een enkel commando de overige phases van de life-cycle laten skippen. Je kunt op deze manier heel simpel een component maken die (HTML) code rendert met URL references erin en die geheel autonoom laten afhandelen. Denk bv aan componenten die img tags neerzetten of die javascriptjes renderen die AJAX requesten doen. In de meeste andere aanpakken die ik zag moest je voor componenten die dergelijke dingen deden aparte servlets declareren in web.xml.
Nog een ander groot punt van flexibiliteit is dat zowel aan de voorkant als aan de achterkant JSF componenten in principe technology onafhankelijk zijn. Met aan de achterkant bedoel ik de techniek waarmee je de componenten bundeld tot een GUI layout. De standaard techniek daarvoor is via taglibs in een JSP pagina. Maar JSF zelf staat compleet los van JSP. Je kunt gewoon je eigen templating techniek gebruiken of zelfs een layout van de componenten in pure java (als desktop gui's dus) samenstellen. Een bekend project wat precies dit doet is facelets. Facelets is geen concurrent van 'standaard' JSF, maar gewoon een alternatieve manier om een layout te maken helemaal volgens de bedoeling van de spec. Met de voorkant bedoel ik dat in principe hetgeen JSF componenten genereren techniek onafhankelijk is. Zowel renderers als renderkits zijn pluggable. In de praktijk werkt dit overigens niet altijd zo makkelijk als het klinkt, omdat niet perse componenten uit verschillende libraries dezelfde alternatieve renderkit hoeven te ondersteunen. Daarbij is de gedachte van even een renderkit wisselen om voor 1 pagina een alternatieve rendering te maken ook grotendeels een illusie. Als je bijvoorbeeld wilt switchen tussen HTML en CHTML, dan wil je waarschijnlijk voor CHTML ook een alternatieve layout (je wilt sommige componenten gewoon helemaal weg hebben), zodat je alsnog 2 pagina's schrijft en onderhoud. Perfect is dit laatste dus niet, maar de aanzet is er zeker.
Vervolgens is ook nog de gehele EL implementatie pluggable. Je kunt hier dus 'gewoon' een eigen taaltje voor schrijven als je wilt of de standaard EL decoraten.
Natuurlijk zijn er nog wel wat punten van kritiek, maar hey, was Spring ---perfect--- in de allereerste versie die als release werd gekenmerkt?
Al met al ben ik redelijk onder de indruk van JSF en ik kijk dan ook zeer zeker uit naar de eerste implementatie van de final.
[
Voor 100% gewijzigd door
Verwijderd op 05-05-2006 22:26
]
/u/92525/me.png?f=community)
:strip_icc():strip_exif()/u/6988/greg.jpg?f=community)
:strip_icc():strip_exif()/u/46177/FoX-icon.jpg?f=community){kind=icon}
:strip_exif()/u/31626/eend.gif?f=community)
:strip_icc():strip_exif()/u/749/crop5f57e8bdbe9f4_cropped.jpeg?f=community)
