[jsf] Wie gebruikt het al?

[flowerp]

Een tijdje geleden heeft Sun een spec opgesteld die eindelijk een model 2 omgeving (MVC) standaard in Java EE brengt. Deze spec heet JSF oftewel Java Server Faces.

Net zoals heel Java EE is het nadrukkelijk een spec en geen project. Wel is er van Sun zelf een reference implementatie (RI). Deze reference implementatie zou je als een soort van technology previeuw kunnen zien. Net zoals met Java 1.1 en Swing destijds, kun je de JSF library nu alvast uitproberen op een oude Java EE 1.4 AS. In de komende versie van Java EE (1.5 dus), zal JSF echter standaard onderdeel van Java worden.

Momenteel is JSF dus nog een losse add-on. Ik verwacht dat wanneer het standaard in Java is opgenomen, het gebruik een enorme vlucht zal nemen. Kijk maar naar Swing. Als je nu een desktop java application bouwt dan is Swing gewoon de default keuze. Slechts heel weinig mensen zullen vandaag de dag nog voor een pure AWT applicatie keuzen (slechts heel weinig mensen bouwen uberhaupt Java desktop applicaties, maar dat even terzijde).

Echter het is dus nog niet zo ver dat JSF standaard in java zit. Aangezien die volgende versie nog heel erg lang kan duren, vraag ik me af of er mensen zijn die nu al JSF gebruiken of dat iedereen liever wacht tot het standaard in Java zit?

[bazzs2001]

Persoonlijk heb ik er naar gekeken maar ik mis persoonlijk nog goede support in de tools. De Eclipse plugin was (een paar weken geleden) nog niet te downloaden.

Ik vond JDeveloper (van Oracle) niet prettig werken en ik heb ook JBuilder hielp me (nog) niet genoeg, maar van JBuilder beschik ik niet over de laatste versie (ik gebruikte 2005 Enterprise, misschien moet ik een trial van 2006 eens gaan downloaden, maar over 2005 kan ik gratis beschikken via de TU/e).

Een project van Apache myfaces houdt zich ook bezig met JSF.

[flowerp]

Opmerkelijk. Het blijft toch bij mensen die slechts erna kijken, eigenlijk niemand die het ook -echt- gebruikt. Vergelijk dat eens met Ruby on Rails wat toevallig ook hier besproken wordt. Veel onvolwassener dan JSF, NOG minder toolsupport, maar mensen gebruiken het gewoon, bouwen er gewoon apps mee die ze al echt aan klanten uitleveren.

Waarom zit iedereen nou zo te wachen met JSF?

Persoonlijk snap ik ook niet helemaal waarom veel mensen nou zo perse die tool support willen. Het is super eenvoudig om er gewoon zo mee te werken. Die tool support (drap en drop van widgets op je page & visueel overzicht van je navigation rules & config files), is natuurlijk leuk maar niet perse noodzakelijk. Voor alle andere taglibs die ik gebruik (bv van Apache Jakarta, of de populaire displaytag) heb ik ook geen tools, maar je zet ze gewoon op je page neer in text:

code:

<myspace:mytag source="${somebean.someData}" >
    <myspace:mychildtag property="foo" />
</myspace:mytag>

Zoiets dus, en dat dan voor de verschillende componenten die je neerzet. Werkt ook zonder tools al stukken overzichtelijker dan scriptlets (blokken javacode) op je page.

Tool support is er momenteel al wel wat hoor. Kijk maar eens naar wat MyEclipse te bieden heeft. Het is nog niet super veel, maar voor navigation rules en de config file zit er al support in.

Zie:
http://www.myeclipseide.c...ress-display-ceid-56.html en

http://www.myeclipseide.c...ress-display-ceid-70.html (even zoeken op "jsf")

Het is wel zo dat het inderdaad wat lang duurt allemaal, je vraagt je af of elke tool vendor op tijd klaar is voordat Java EE 1.5 gereleased wordt. Aangezien dat nog zeker wel een jaar kan duren, en bijna elke tool vender er hard mee aan de gang is denk ik dat het wel gaat lukken.

[Apache]

Binnenkort is er het Cherokee project van Apache, wat basicly de open source release van ADF faces (Oracle) is. Ik heb enkele weken geleden Javapolis in Antwerpen bijgewoond, oa de sessie over JSF en waar ze toen ook meteen het Cherokee project aankondigden. Nu zijn er blijkbaar nog enkele kleine obstakels maar deze week zou de source beschikbaar moeten komen volgens de blog van Jonas Jacobi. Ik moet zeggen dat ik ervoro al naar myfaces had gekeken en al wel wat onder de indruk was maar ADF was zeeer indrukwekkend, veel AJAX (of gewoon dhtml, ipv de mode-term) gebruik waardoor er echt mooie zaken mogelijk zijn. Zij gebruikten een nightly build van JDeveloper (aangezien het oracle personeel was).

Qua ide denk ik dat mss WTP (web tools project), 1.0 die pas is uitgekomen er mss al wel betere support voor heeft, anders komt dit wel in WTP 1.5 of als een apart project mee met eclipse 3.2

[flowerp]

Apache schreef op maandag 02 januari 2006 @ 14:31:
Qua ide denk ik dat mss WTP (web tools project), 1.0 die pas is uitgekomen er mss al wel betere support voor heeft, anders komt dit wel in WTP 1.5 of als een apart project mee met eclipse 3.2

Je kunt het zo nakijken op eclipe.com (geen org meer...), maar uit mijn hoofd doet WTP 1.0 alleen de basic web dingen. Het is de bedoeling dat tool vendors WTP als basis gebruiken en dan higher-level dingen toevoegen. Omdat JSF wel heel basis gaat worden in de Java EE wereld (net zoals JSP dat nu is), gaat geloof ik WTP 1.5 wel inderdaad support voor JSF toevoegen. Ik verwacht dan echter geen visuele drag en drop editor voor componenten op een pagina, maar we zullen zien.

[PhoneTech]

Ik heb zeker intresse in de JSF als standaard in de java web wereld. Er zijn nu zo veel verschillende web frameworks dat je bijna geen overwogen keuze kan maken, maar bijna puur aan smaak is verbonden...en smaken verschillen nu eenmaal.

Ik ben inmiddels al een paar jaar in Swing bezig, en dat bevalt me goed. Maar hier heb ik snel geleerd dat visuele editors alleen maar poepcode genereren. Om even een soort voorbeeld schermpje te maken is het goed te doen, maar voor productie toepassingen met complexe form layouts ben ik sneller en beter af met een goede IDE (eclipe) en layout manager (JGoodies Layout)

Ik denk dat dit ook voor JSF zal gelden. Meestal maak je toch eerst custom componenten om vervolgens in een redelijk standaard layout te zetten. drag & drop support is dan ver te zoeken tenzij je je aan de java beans standaard houdt...

[Apache]

@flowerp: eclipse is een platform dus vaak bedoeld als iets waarop third-party verder bouwt, maar een visual editor zit er al wel in, ik denk dat ze ook hier uiteindelijk zelf wel met een userfriendly oplossing zullen komen
In WTP zijn trouwens ook enkele commerciele toevoegingen van IBM rational application developer gebackport naar 1.0.

@PhoneTech: de gui builder van eclipse al geprobeerd? daar heb ik nl al uitgebreide & complexe gui's mee gebouwd en dat genereerd helemaal geen poepcode
Hier onthou ik graag "designing gui's is a visual task, so use a visual editor".

Er word steeds meer naar tools gegrepen, wanneer ik een domeinmodel opstel doe ik dit meteen in een roundtrip tool van m'n IDE zodat ik meteen in de javacode kan duiken en daar dmv code generation nog wat extra zaken als getters/setters & constructors genereer. Als er dan iets wijzigt in mijn requirements, aangezien je toch in een incrementeel iteratief process zit, kan je meteen tijd besparen doordat meteen je analyse up to date is ook. Het bespaart mij iig een hoop tijd die ik in andere leuke zaken kan steken

[Confusion]

Sun Java Studio Creator is nu ook gratis beschikbaar en leunt zwaar op JSF. Er werd me vanmorgen gevraagd daar naar te gaan kijken, dus ik kom er later nog op terug.

[Verwijderd]

Confusion schreef op dinsdag 03 januari 2006 @ 12:10:
Sun Java Studio Creator is nu ook gratis beschikbaar en leunt zwaar op JSF. Er werd me vanmorgen gevraagd daar naar te gaan kijken, dus ik kom er later nog op terug.

De hele professional suite van Sun wil ik zeker ook nog eens naar kijken. Helaas zijn wij wel helemaal gestandaardiseerd op Eclipse (met name aantal eigen plug-ins ontwikkeld).

Hoewel ik gek van tool-support ben (met name refactorings, code completion, auto-inserts, etc), zit ik zelf niet echt zo te wachten op de visuele tools. 1 van de interfaces van JSF componenten gaat gewoon via taglibs, en die kun je heel erg simpel zelf op een JSP pagina zetten.

JSF ziet er al met al erg veelbelovend uit, met name als de component library markt een beetje op gang gaat komen. Je kan zeggen van Microsoft wat je wilt, maar met ASP.NET hebben ze dit vanaf het begin goed opgepakt. Er is een behoorlijke aantal kant & klare components te koop of vrij te verkrijgen.

[Cuball]

Confusion schreef op dinsdag 03 januari 2006 @ 12:10:
Sun Java Studio Creator is nu ook gratis beschikbaar en leunt zwaar op JSF. Er werd me vanmorgen gevraagd daar naar te gaan kijken, dus ik kom er later nog op terug.

Studio creator is handig om snel iets in elkaar te fletsen, het deed me direct denken aan de visual tool van Microsoft om pagina's te maken in ASP.NET

maar helaas zitten wij grotendeels vast aan eclipse (we maken gebruik van Rational Developer die gebaseerd is op eclipse 3)

maar een plugin die het editen van JSF pagina's versnelt zou handig zijn, dan denk ik bv aan het automatisch toevoegen van de de componenten aan een codebehind bean. Het visuele hoeft voor mij zelf niet.

[Verwijderd]

Zijn er eigenlijk echt zo weinig mensen die JSF gebruiken?

Mischien is het dan een interesantere vraag:

Waarom gebruik jij (als Java developper) JSF NIET?

[Confusion]

Verwijderd schreef op dinsdag 03 januari 2006 @ 21:33:
Hoewel ik gek van tool-support ben (met name refactorings, code completion, auto-inserts, etc), zit ik zelf niet echt zo te wachten op de visuele tools. 1 van de interfaces van JSF componenten gaat gewoon via taglibs, en die kun je heel erg simpel zelf op een JSP pagina zetten.

Ach, voorlopig ziet Studio Creator er voor heel wat projecten prima geschikt uit. Natuurlijk moet de gegenereerde code netjes zijn en moet je wel begrijpen wat er gebeurt, maar als dat zo is en je alles met de hand verder aan kan passen, wat is dan het probleem van een visuele tool?

Verder gebruik ik ook eclipse, maar het kan geen kwaad meerdere development environments te kunnen gebruiken.

Verwijderd schreef op donderdag 12 januari 2006 @ 20:44:
Zijn er eigenlijk echt zo weinig mensen die JSF gebruiken?

Tjah, het oerwoud aan frameworks, de hoeveelheid FUD en het feit dat het hele java webapp gebeuren ontzettend overengineered is maakt het niet makkelijk om te besluiten iets als JSF te gebruiken. In principe is JSF, IMHO, heel eenvoudig, alleen kan het soms een lange zoektocht zijn om uit te vogelen hoe iets nu precies moet. Zeker als je met dingen door elkaar werkt: de interactie tussen JSP, JSF en Struts is, aan de daaraan gewijde weblogentries en andere verslagen te zien, niet direct logisch.

[ Voor 3% gewijzigd door Confusion op 12-01-2006 21:22 ]

[Verwijderd]

Confusion schreef op donderdag 12 januari 2006 @ 21:22:
wat is dan het probleem van een visuele tool?

Geen enkel probleem natuurlijk. Ik zou best blij zijn als er meer en betere visuele tools waren. Wat ik vooral bedoelde is dat het voor mijzelf geen noodzaak is. Alle taglibs (JSTL, eigen dingen, etc) die ik tot nu toe heb gebruikt typte ik gewoon op de JSP pagina in. Kwa JSP werk is JSF ook 'gewoon' een taglib, maar dan zelfs simpelder in te typen als JSTL. Daarom heb ik het niet *perse* nodig, dat visuele.

Wat ik nog wel jammer vind aan JSF is dat het nog helemaal op Java SE 1.4 is gestoeld. Voor een techniek die standaard in Java EE 5 zal komen te zitten is dat niet super. Nu heb je bv methods als getChildren die een List teruggeven. Maar na een tijdje met Java SE 5 gewerkt te hebben weet ik al niet eens meer wat een List is en verwacht ik overal een List<Something> terug te krijgen.

Zelfde voor annotations support. Sommige mappings in faces.config.xml zou je mooi op kunnen vangen hiermee.

Ik heb bijvoorbeeld vaak dingen staan als:

XML:

<component>
        <component-type>com.mycompany.jsf.MyComponent</component-type>
        <component-class>com.mycompany.jsf.MyComponent</component-class>
</component>

Nu ik een tijdje met EJB3 (via beta entity manager en Hibernate 3.1) aan het werk ben geweest, heb ik eigenlijk geen zin meer om dergelijke XML mappings te maken en te onderhouden.

Verder gebruik ik ook eclipse, maar het kan geen kwaad meerdere development environments te kunnen gebruiken.

inderdaad!

Tjah, het oerwoud aan frameworks

Het mooie aan JSF is dat het gewoon standaard in Java komt. Daarmee is het in veel gevallen een eerste keus, ook al zou framework X op punt Y beter zijn. Neem nou JSP als template engine. Dat wordt heel veel gebruikt. Mischien is Velocity wel beter als JSP, maar gewoon het feit dat JSP alweer heel erg lang gewoon standaard in Java zit maakt het zo populair.

, de hoeveelheid FUD en het feit dat het hele java webapp gebeuren ontzettend overengineered is maakt het niet makkelijk om te besluiten iets als JSF te gebruiken.

Zelf vind ik het eigenlijk helemaal niet over-engineerd over komen. Het is bijna een directe doorontwikkeling van Struts, een framework en aanpak die zich in de praktijk ruimschoots bewezen heeft. Alle best practices daaruit zijn meegenomen in JSF, alsmede veel lessen die geleerd zijn van andere frameworks.

Vergeet ook niet dat JSF als standaard component framework eigenlijk erg laat is in de Java wereld. Sun beschreef het model 2 concept (MVC voor het web in sun's termen) als heel lang geleden, maar stelde er nooit een concrete spec voor op. Microsoft kwam voor asp.net veel eerder met een degelijk component en MVC framework.

Als Sun nou meteen in 1 van de allereerste J2EE specs een MVC spec had ondergebracht, dan had het mischien als overengineered kunnen overkomen. Met EJB2 hebben ze die fout wel gemaakt. Maar 2 van de belangrijke onderdelen van Java EE 5 zijn gebasseerd op concreet gebruik en ervaringen in de industrie (EJB3 -> hibernate, en JSF -> Struts).

Zoals Hibernate (EJB3) abstraheerd van de low-level DB details als je gewoon Objecten wil hebben, zo abstraheerd JSF grotendeels van het low-level geneuzel met html, responses en request parameters die je handmatig moet controleren en in Objecten moet gaan omzetten.

Zeker als je met dingen door elkaar werkt: de interactie tussen JSP, JSF en Struts is, aan de daaraan gewijde weblogentries en andere verslagen te zien, niet direct logisch.

Dat is momenteel inderdaad zo. Vooral de interactie met andere JSP elementen en de JSF componenten is niet super. Content interweaving probleem, JSTL constructies zoals foreach die niet met JSF componenten werken (eigenlijk zou je dit niet moeten willen, maar goed), etc.

De versie van JSF die standaard met Java geleverd gaat worden zal licht verschillen van de versie die je momenteel los kunt downloaden, maar zal juist deze punten goed aanpakken:

JavaServer Faces 1.2 provides a minimal enhancement of the JavaServer Faces 1.1 specification. It is not a new feature JSR. The primary goal of this JSR is handling the Faces side of the JSP/Faces alignment issues

(zie http://jcp.org/en/jsr/detail?id=252)

[ Voor 5% gewijzigd door Verwijderd op 12-01-2006 23:29 . Reden: bron toegevoegd ]

[flowerp]

Verwijderd schreef op donderdag 12 januari 2006 @ 22:11:
[...]
JavaServer Faces 1.2 provides a minimal enhancement of the JavaServer Faces 1.1 specification. It is not a new feature JSR. The primary goal of this JSR is handling the Faces side of the JSP/Faces alignment issues

(zie http://jcp.org/en/jsr/detail?id=252)

Die integratie is op meerdere punten inderdaad nog niet ideaal. Het hoofdpunt van JSP 2.1 en JSF 1.2 is dan ook de unified EL. Nu zit je met de vervelende situatie dat je met JSF EL in je TLD geen runtime expression en types gebruikt. Bijvoorbeeld, als je iets doet als:

XML:

<foo:bar kaz="#{bean.value}" />

dan krijgt het component kaz niet een object binnen, maar letterlijk de string "#{bean.value}", hier moet het component dan zelf via de jsf context een valuebinding van laten maken, waaruit je dan weer het eigenlijk object kunt krijgen. Dit is natuurlijk logisch, want de container kent helemaal geen JSF EL, maar je TLD's komen er wel raar uit te zien en je taghandlers komen bol te staan van boilerplate code die nergens voor nodig is.

Vroeger met de oude JSP versies wat gewoon EL ook nog zo'n add-on die door de taghandlers zelf werd ge-execute. Eigenlijk jammer dat ze met JSF dan weer diezelfde fout hebben moeten maken. (-moeten-, omdat anders JSF nooit als een .jar filetjes aan bestaande application servers had kunnen worden toegevoegd)

[Ti_Uhl]

ik denk dat het beter is nog even te wachten tot jsf daadwerkelijk in EE 1.5 zit.

Ik heb ook jsf ook al eens bekeken, wel nog niet mee gewerkt en het ziet er allemaal veelbelovend uit maar ik vind het momenteel allemaal nog maar wat onoverzichtelijk en wacht liever nog even tot het een beetje mainstream word.

[Kwistnix]

Hebben jullie ook wel eens interfaces gebouwd met Macromedia Flex of (Open)Laszlo?
Dit soort alternatieven vind ik zelf heel erg interessant, omdat je er waanzinnig mooie dingen mee kan doen en het redelijk eenvoudig is in het gebruik. Aan de andere kant ben je wel afhankelijk van Flash, maar ik denk persoonlijk niet dat dat een erg groot nadeel is.

[flowerp]

Ti_Uhl schreef op zondag 15 januari 2006 @ 00:15:
ik denk dat het beter is nog even te wachten tot jsf daadwerkelijk in EE 1.5 zit.

Mischien wel ja. Voor developpers is het natuurlijk wel leuk dat je er toch alvast mee aan de gang kunt en zo ervaring op kunt doen. Ik denk terug aan vacatures toen C# net uit waren die vroegen om 2 jaar C# ervaring. Als JSF eindelijk uit komt dan kun je dat nog ook echt zeggen ook, als je al 2 met de preview versie hebt gewerkt.

Wel jammer vind ik dat het nog steeds compleet niet duidelijk is wanneer EE 1.5 nu komt. De originele JSR staat op voorjaar 2006, heel erg binnen kort dus. Maar de JSR is al oud, en JSR's mogen bijna nooit geupdate worden. Zo zie je dikwijls op een JSR data staan die al lang voorbij zijn.

Dan nog de vraag, als de specificatie eenmaal gereed is, wanneer komt dan Tomcat ermee? Tomcat is toch het meeste mainstream bij iedereen. Als Tomcat dus niet met een nieuwe versie komt gebruikt nog niemand het.

edit:
Deze post op de mailing-list geeft aan dat net begonnen is met de entry in SVN te maken voor Tomcat 6. Zie: http://[e-mail]%3e

Je zou dus kunnen verwachten dat het nog +- 1 jaar duurt voor Tomcat 6, Dan nog een jaar erbij omdat je software pas na een jaar mag gebruiken. Dus dan zit je op +- begin 2008 voordat mensen JSF gaan gebruiken.

Eigenlijk is dit wel jammer, want in ASP.NET gebruiken de mensen al jaren een JSF achtige aanpak.

[ Voor 22% gewijzigd door flowerp op 15-01-2006 09:35 ]

[flowerp]

FallenAngel666 schreef op zondag 15 januari 2006 @ 00:36:
Hebben jullie ook wel eens interfaces gebouwd met Macromedia Flex of (Open)Laszlo?
Dit soort alternatieven vind ik zelf heel erg interessant, omdat je er waanzinnig mooie dingen mee kan doen en het redelijk eenvoudig is in het gebruik. Aan de andere kant ben je wel afhankelijk van Flash, maar ik denk persoonlijk niet dat dat een erg groot nadeel is.

Doel je nu op de Flash renderer-kit van JSF?

Ik heb daar zelf nog helemaal geen ervaring mee. Sinds het prille begin van JSF is er al sprake van dat je via de renderkits in principe naar elke technology kan renderen. Zo zouden PDF renderers, en WAP renderers ook al tot de mogelijkheden behoren. Vooralsnog blijft de HTML renderkit wel de meest dominante kit, evenals JSP het meest gebruikt is als interface voor JSF componenten.

JSP taglibs zijn meestal maar een hele dunne wrapper om de eigenlijke componenten heen. De eigenlijke componenten kun je net zo goed in Java code aan elkaar knopen, of je kunt je eigen interface taaltje schrijven die geinterpreteerd wordt door een eigen interpreter die dan gestuurd door dat taaltje de JSF componenten verbind. Je kunt dan bijvoorbeeld via XUL je interface beschrijven en Flash als output laten genereren. Dit lijkt dan in de eerste instantie compleet anders als het gebruikelijke JSF, maar het hele framework zelf blijft geheel hetzelfde.

Maar jij hebt dus ervaring met de Flash renderings van JSF? Bevalt dat nog een beetje?

[Confusion]

Verwijderd schreef op donderdag 12 januari 2006 @ 22:11:
Zelf vind ik het eigenlijk helemaal niet over-engineerd over komen.

Dat sloeg niet op JSF, maar op het hele web-app gebeuren. Alleen al die directory structuur, het aantal verschillende config files, alle frameworks met hun verschillende manieren van werken en opmaak. Het punt was dat men daardoor minder snel een nieuwe technologie durft te adopteren, omdat de interactie met alle andere aspecten goed bekeken moet worden. Daardoor wordt JSF ongetwijfeld als ingewikkelder gezien dan het is.