[Java EE] Wat gebruikt iedereen vandaag de dag?

[flowerp]

Een topic zoals deze is natuurlijk al vaker langsgekomen, echter de laatste was al weer een flink tijdje geleden.

Ondertussen zijn de ontwikeling natuurlijk ook verder gegaan in Java land. Wist bij de vorige topic nog slechts een minderheid wat JSF was ("ziet er wel mooi uit, maar nog niet gebruikt", "moet ik nog eens ervaring mee opdoen", etc), ondertussen is JSF officieel gereleased en een standaard onderdeel van Java.

In de vorige topics werd het loodzware EJB 2.x dikwijls afgebrand, en Spring naar voren geschoven als het "light weight' alternatief. Ondertussen lijkt het wel andersom: EJB3 is enorm veel makkelijker geworden, terwijl Spring relatief veel zwaarder is geworden. Met Spring kan meer dan ooit, maar het is ook complexer geworden.

Daarnaast zijn er een aantal complete nieuwe projecten ontstaan, die in de vorige edities van een dergelijk topic nog helemaal niet bestonden, ik noem met name Facelets en Seam.

In tegenstelling tot het eerdere oerwoud van frameworks (struts, tapestry, webworks, etc), zie je met Facelets en Seam dat ze geenzinds (weer) een compleet alternatief willen zijn, maar dat ze een specificiek onderdeel van standaard Java EE vervangen of ondersteunen.

Zo is facelets een templating systeem dat veel natuurlijker aansluit bij JSF dan het oude JSP dat doet. JSP zelf staat eigenlijk los van JSF. Om practische redenen is het 'slechts' het default templating system, maar in de spec staat al vanaf het begin dat het zo is opgezet dat er makkelijk andere templating systems toegevoegd kunnen worden.

Seam is dan weer een project dat direct bouwt op zowel EJB3 als JSF (met JSP of Facelets, dat maakt nix uit) en simpel gezegd de verschillende component modellen bij elkaar brengt en zoiets handigs introduceerd als de conversation context. Dit laatste is een oplossing voor het feit dat de session context vaak te groot is, en de page context te klein. MyFaces had hier al een mooie tussen oplossing voor met de super simpele maar erg effectiefe saveState tag, maar Seam brengt het nog een niveau'tje hoger.

Nu de kaarten dus opnieuw geschud lijken te zijn, vraag ik me of wat de mede Java EE developpers hier gebruiken? Is iedereen nog op de keuzes van de vorige ronden blijven hangen (bv Struts), of gebruikt iedereen ondertussen al weer wat nieuws? Zijn er mensen die concreet JSF 1.2 gebruiken? Zijn er al mensen die de (gewaagde) overstap naar Java 5.0 hebben durfen te maken?

[-FoX-]

Zo gewaagd is die overstap naar Java 5.0 anders niet hoor, maar ik merk wel dat er nog veel bedrijven zich blijven vasthouden aan versie 1.4. Op hobby projecten gebruik ik alvast Java5 en ben er erg tevreden mee (generics, autoboxing en enums zijn zowat mijn favorieten).

Op het vlak van enterprise development, lijkt mij er ook niet zoveel veranderd te zijn. EJB 3 lijkt dan in de tegenaanval te gaan om enterprise development te vereenvoudigen, terwijl de web zijde nog steeds moet afrekenen met heavyweight alternatieven. Ik zie JSF nog altijd nergens komen en het lijkt me veel te log in gebruik te zijn waar je al gauw de controle over verliest.

Natuurlijk zijn er wel de vendor tools die een deel van dit zware werk uit handen nemen, neemt niet weg dat het nog altijd een onhandige manier van werken blijkt. Dit verklaard onder andere seam, die een nauwere integratie van heel het JEE gebeuren wil stellen, al heb ik geen zicht of dit nog maar enigzins lijkt te lukken...

Met andere woorden, ik maak nog steeds geen gebruik van de nieuwe alternatieven die Sun biedt. Ik kan overigens prima overweg met de open-source alternatieven die toch wel een defacto standaard zijn geworden (Spring, Hibernate, Struts, ...).

De opkomst van Ajax heeft blijkbaar ook een en ander door elkaar gegooid. Opeens wordt daar ook de focus naartoe gelegd, hetgeen de focus weer afhaald van de belangrijkere zaken (voor Sun althans). Ik weet niet of heel het JSF/Facelets/Seam gebeuren echt een goede zet is. Buiten het feit dat het een standaard is, zie of hoor ik nergens succesverhalen... en denk eigenlijk ook niet dat het al zo vaak gebruikt wordt.

Ik geloof nog altijd in de toekomst van Spring. Alleen hoop ik dat het niet te rommelig gaat worden, waardoor het onoverzichtelijk wordt. Voor mij is het dus nog steeds Spring en Hibernate wat de klok slaat.

Al denk ik niet dat daar alleen de focus op gelegd mag worden. Ik zie ook dat er meer moeite gedaan wordt om het buildproces te standaardiseren, een continuous build server opgezet wordt en de build tools geupgrade worden (ant->maven2).

[flowerp]

-FoX- schreef op zaterdag 09 september 2006 @ 15:59:
Ik zie JSF nog altijd nergens komen en het lijkt me veel te log in gebruik te zijn waar je al gauw de controle over verliest.

Je zegt "lijkt me veel te log", betekent dat dan dat je tot deze mening gekomen bent omdat je in blogs hebt gelezen dat het log zou zijn, of heb je het goed bestudeerd (en mischien wel gebruikt) en kwam je toen tot die mening?

Dit is absoluut geen flame hoor, ik ben heel nieuwschierig naar waarom dit zo zou zijn.

Kun je mischien aangeven welke elementen precies 'log' zijn volgens jou?

[-FoX-]

flowerp schreef op zaterdag 09 september 2006 @ 16:24:
Je zegt "lijkt me veel te log", betekent dat dan dat je tot deze mening gekomen bent omdat je in blogs hebt gelezen dat het log zou zijn, of heb je het goed bestudeerd (en mischien wel gebruikt) en kwam je toen tot die mening?

Dit is absoluut geen flame hoor, ik ben heel nieuwschierig naar waarom dit zo zou zijn.

Kun je mischien aangeven welke elementen precies 'log' zijn volgens jou?

Ik heb gehoord dat het erg log zou zijn. Inderdaad, ik heb zelfs nog niet eens de moeite gedaan om het te bestuderen... of jawel, éénmaal maar ben er toen ook gauw mee gestopt omdat ik alles zelf moest samen zoeken en er nergens een consistente 'handleiding' oid beschikbaar was (is alweer 2 jaar geleden denk ik).

Nouja, log en onwerkbaar.. Dat is tenminste wat ik hoor van collega's, lees in blogs, etc.. Samen met het feit dat het werkbaar is gemaakt door allerhande vendor tools etc, maar dat zou in de eerste plaats al niet de bedoeling mogen zijn. EJB2.x was ook werkbaar met de juiste tools.... ik bedoel maar. JSF lijkt me heeel sterk op EJB2.x, en omdat er leukere alternatieven zijn Struts/Spring MVC, Wicket, ... houd ik het er voorlopig liever daarop!

[BalusC]

Ik werk dagelijks met Websphere / JEE en dan in het bijzonder webservices en webapplicaties (de zgn. Dynamic Web Projects, gebaseerd op WSDL's). Ik werk praktisch elke dag met JSF en backing beans en ik vind deze geeneens log. Ik denk dat deze indruk komt doordat bijvoorbeeld de autogenerated IBM's pagecode zooi in Websphere inderdaad behoorlijk overdone is, grofweg zowat 60% van de gegenereerde pagecode zooi is volledig overbodig. Maar wanneer je Websphere's WYSIWYG JSF-editor resoluut aan de kant zet en het lekker zelf codeert dan kun je zeker wel wat moois uit bakken En dit geldt ongetwijfeld ook voor WYSIWYG JSF-editors van alle andere IDE's.

Met Facelets en Seam (en Struts) heb ik persoonlijk nog geen professionele ervaring. We bouwen en gebruiken voornamelijk onze eigen frameworks gebaseerd op JSF. Met Facelets heb ik wel hobbymatige ervaring. De enige opensource product die hier zeer regelmatig wordt gebruikt is Hibernate (icm DB2) en in de mindere mate worden er enkele opensource producten van Apache gebruikt (MyFaces, Log4j, RE, Ant, etc). Ook komt hier AJAX om de hoek kijken, er wordt al mee geëxperimenteerd icm onze frameworks en vooralsnog ziet het erg goed uit

De gebruikte versies zijn op werk overigens nog J2EE 1.4 en JSF 1.1. Hobbymatig gebruik ik wel JEE 5.0 en JSF 1.2. Op werk zou de overstap naar JEE 5.0 an sich geen punt zijn, echter de overstap naar JSF 1.2 vraagt wel iets meer werk, aangezien het EL gebeuren nogal op de schop is geweest ten op zichte van JSF 1.1, waardoor aardig wat methoden deprecated raakten. Daar houden we nog wel rekening mee met de huidige ontwikkeling.

[JKVA]

Bij mij op het werk (één van de grootste IT'ers in NL) is iedereen ongeveer over op JSF. Bestaande projecten blijven nog wel op Struts/Tapestry/oid, maar voor de nieuwe projecten wordt steeds JSF gebruikt. Ben ik blij om, aangezien ik bij ons als één van de eerste met JSF begonnen ben. Ook Facelets promoot ik en een aantal met mij dagelijks en ik merk dat dat ook resultaat heeft, vooral omdat het simpelweg beter is dan JSP. Moet alleen nog eens goed naar ADF/BackBase/Shale gaan kijken, maar het is helaas wat druk, waardoor het erbij inschiet.

Ps. JSF is niet log. Het is een iets andere manier van werken waar je even aan moet wennen, ook is het een spec die nou eenmaal door meerdere partijen is samengesteld. Ook is versie 1.1 niet je van het, maar ik merk duidelijke progressie per (minor) release. (dat is overigens MyFaces)

De vendors beginnen JSF ook te kennen. Zie IBM, Oracle, IceFaces, BackBase, etc, en dat is allemaal positief voor de concurrentie met bijv. India...

Ajax begint ook een beetje bekendheid te krijgen merk ik. Ik heb er op mijn vorige werk al een paar jaar mee ontwikkeld en ken het dus al wel even, maar ik zie dat steeds meer mensen het beginnen te vatten en alles met Ajax willen gaan doen. Zeker met tools als DOJO is Ajax goed te gebruiken, het oogt alvast 10x beter dan die oldskool stijl zoals ik nog gewend ben.

EJB is een ander verhaal. We hebben een aantal mensen die echt ver zijn met EJB 3.0, maar nog niet veel en het is zo ver ik weet nog niet in de praktijk ingezet. Wel heb ik binnenkort een ontwikkeldag EJB 3.0 om het aan den lijve te ervaren of het iets is...

We zijn er veel met Maven 2 bezig. De ontwikkelstraat draait er namelijk op. Dit wordt ondersteund doordat we iemand hebben met zeer veel Maven 2 ervaring. Zit bij Apache en dergelijke.

Ook is volgens mij J2EE 1.4 (en Java 5) momenteel de standaard. Op mijn huidige project is dat bijvoorbeeld omdat het op WAS 6 moet gaan draaien en we niet met GlassFish aan kunnen komen kakken. Die generics ownen echt, behalve als je ze in een EJB interface gebruikt, dan gaat XDoclet over de flos...

Verder denk ik dat Spring en Hibernate nog wel even blijven, ondanks Persistency API's en EJB 3, omdat er veel ervaring in deze frameworks zit.

[flowerp]

JKVA schreef op zaterdag 09 september 2006 @ 20:09:
Ps. JSF is niet log. Het is een iets andere manier van werken waar je even aan moet wennen, ook is het een spec die nou eenmaal door meerdere partijen is samengesteld.

Inderdaad. Voor al onze oude projecten gebruikte wij voordat we met JSF begonnen eigenlijk alleen JSTL i.c.m. een serie eigen taglibs. Voor slechs een paar projecten is Struts gebruikt. De angst om 'controlle' te verliezen zat er sterk in bij sommige van de developpers. Omdat we toch met onze tijd mee wilde, zijn we JSF heel erg grondig gaan analyseren. Er kwamen wel een aantal kleine probleempjes aan het licht (zoals de URL die je in je adres balk ziet vaak 1 achter loopt op de view die je daadwerkelijk ziet), maar voorderest bleek het juist VERRE van log.

Hoe defineer je log? Voor mij is dat als een framework me tot allemaal dingen dwingt die ik zelf anders wil doen. Zoals een olietanker log wordt genoemd omdat het bijna onmogelijk is zo'n ding snel van richting te laten veranderen.

JSF is wat dat betreft extreem flexibel. Dingen die je absoluut als 'core' functionaliteit zou zien, kun je gewoon vervangen door eigen implementaties als je dat wilt. De zogenaamde extention points zijn enorm groot: op bijna elk punt van de zogenaamde life-cycle kun je wel inhaken met eigen code. Hiervoor heb je bijvoorbeeld dingen als de PropertyResolver, VariableResolver, ActionListener, NavigationHandler, ViewHandler, StateManager of de PhaseListener. Die eigen code kan dan iets toevoegen aan de default implementatie, of naar keuze deze compleet vervangen.

Zo slaat JSF standaard de state van de GUI componenten op een bepaalde manier op. Dit wordt de viewstate genoemd. Je zou zeggen dat deze manier van opslaan 1 van de grondslagen van het framework is, maar niets is minder waar. Voeg je eigen viewhandler plug-in toe, en je bepaald voortaan helemaal zelf hoe en van waar de state komt.

Sleutel concept is dat je dit niet HOEFT te doen. Alle defaults werken voor de meeste situaties uitstekend, maar als je wilt, kun je dus bijna alles vervangen wat los en vast zit.

Verder denk ik dat Spring en Hibernate nog wel even blijven, ondanks Persistency API's en EJB 3, omdat er veel ervaring in deze frameworks zit.

In principe zit Hibernate natuurlijk ook standaard in Java EE nu. JPA (Java Persistence API) wat een onderdeel van EJB3 is, -is- eigenlijk gewoon Hibernate wat tot een spec is verheven. Het is dan ook niet gek dat Hibernate ook direct JPA implementeerd.

De Java EE 5 servlet spec biedt ook een (simpele) vorm van DI. Probleem van Java EE 5 is natuurlijk dat eigenlijk alleen Glass Fish en diens commerciele tegenhanger het implementeerd. Bij veel klanten kun je daar (terrecht of onterrecht) eigenlijk inderdaad niet mee aan komen zetten.

1 project waar ik ook erg tevreden over ben is Quartz. In zekere zin concureerd het wel een beetje met de concurency APIs in Java 5, maar waar die laatste meer als een util lib bedoeld is voor het bouwen van je eigen parallele algortimes/systemen is Quartz gewoon heel makkelijk om even snel een stukje code op een bepaald tijdstip te laten draaien.

[JKVA]

flowerp schreef op zaterdag 09 september 2006 @ 23:00:
[...]
JSF is wat dat betreft extreem flexibel. Dingen die je absoluut als 'core' functionaliteit zou zien, kun je gewoon vervangen door eigen implementaties als je dat wilt. De zogenaamde extention points zijn enorm groot: op bijna elk punt van de zogenaamde life-cycle kun je wel inhaken met eigen code. Hiervoor heb je bijvoorbeeld dingen als de PropertyResolver, VariableResolver, ActionListener, NavigationHandler, ViewHandler, StateManager of de PhaseListener. Die eigen code kan dan iets toevoegen aan de default implementatie, of naar keuze deze compleet vervangen.

Zo slaat JSF standaard de state van de GUI componenten op een bepaalde manier op. Dit wordt de viewstate genoemd. Je zou zeggen dat deze manier van opslaan 1 van de grondslagen van het framework is, maar niets is minder waar. Voeg je eigen viewhandler plug-in toe, en je bepaald voortaan helemaal zelf hoe en van waar de state komt.

Sleutel concept is dat je dit niet HOEFT te doen. Alle defaults werken voor de meeste situaties uitstekend, maar als je wilt, kun je dus bijna alles vervangen wat los en vast zit.
[...]

Extreem flexibel is imho weer helemaal de andere kant van de waarheid. Als je zelf een StateManager moet maken omdat die van JSF niet voldoet, mankeert er toch iets aan JSF lijkt me. Het KAN, dat klopt, maar de standaard moet wel zo goed zijn dat het bijna altijd voldoet.

Dat doet het ook wel redelijk, maar aan de andere kant walg ik bijvoorbeeld van de gegenereerde HTML. Momenteel krijgen we in mijn huidige project HTML bestanden van megabytes over het lijntje, puur en alleen omdat JSF per-se achterlijk veel JavaScript gaat lopen genereren per hyperlinkje. Als ie dat nu eens wat slimmer deed, zoals één functie die steeds aangeroepen wordt...

Dat zou een hoop ellende schelen.

Ook vind ik achteraf dat het een vrij hoge leercurve heeft, zeker als je meer wilt dan alleen navigatie en beans, maar bijvoorbeeld ook zelf componenten, converters, etc. maken.

[momania]

Ik heb me nu met 2 projecten volledig op Wicket gestort en ik ben er erg tevreden mee. De uitbreidingen op het framework worden steeds completer. Ajax support is een fluitje van een cent en de templates zijn gewoon kale html's. Gegenereerde output is er bijna niet (behalve het ajax deel dan), dus de vorm en grootte van je html heb je ook helemaal zelf onder controle. Alles is dus perfect xhtml compliant.

Gewoon heerlijk OO web devven, geen lastig template werk, vrij simpel te leren (iig simpeler dan alle andere frameworks imo) en development tijd wordt drastisch verkort.

[ari3]

flowerp schreef op zaterdag 09 september 2006 @ 23:00:
[...]1 project waar ik ook erg tevreden over ben is Quartz. In zekere zin concureerd het wel een beetje met de concurency APIs in Java 5, maar waar die laatste meer als een util lib bedoeld is voor het bouwen van je eigen parallele algortimes/systemen is Quartz gewoon heel makkelijk om even snel een stukje code op een bepaald tijdstip te laten draaien.

Vind ik een interessant statement. Kun je aangeven waarom Quartz te verkiezen is boven de J2EE implementaties van timers en schedulers?

[Alarmnummer]

ari3 schreef op zondag 10 september 2006 @ 20:17:
[...]
Vind ik een interessant statement. Kun je aangeven waarom Quartz te verkiezen is boven de J2EE implementaties van timers en schedulers?

Hij bedoelt de JSE 5 functionaliteit voor timers. Met Quartz kan je cron expressies schrijven en dat kan je met de java.util.Timer en java.util.concurrent.ScheduledExecutor niet.

Er is wel een voorstel om JSR166 (met oa die ScheduledExecutor) ook binnen JEE 5 omgevingen te kunnen gebruiken maar dat zal uiteraard nog wel even duren.

[ReLight]

#Balusc "We zijn er veel met Maven 2 bezig. De ontwikkelstraat draait er namelijk op. Dit wordt ondersteund doordat we iemand hebben met zeer veel Maven 2 ervaring. Zit bij Apache en dergelijke.
"

Hoe bevalt dit ? Wij hebben echt een erg groot Ant build deploy systeem waar zo te vergelijken alles wat Maven nu bied uitgewerkt is in eigen taskdefs, extensions en macrodefs. Dit is een 3 laags systeem met developers, buildserver(s) en als laatste een samenstelling aangezien ons product als geheel gedeployed wordt uit 1 gemeenschappelijk platform + n applicaties.
Ik zie de voordelen niet echt in van Maven2 als ik erg veel moeite moet doen om toch weer afwijkingen van het ge-eikte erg omslachtig moet gaan (laten) maken. (ben zelf geen java-dev, maar kan wel goed met ant overweg).

/ontopic
Verder kan ik de terughoudendheid van overgang van 1.4 naar 5 wel beamen, maar dit gaat veelal veel verder dan overgangs angst. Ook de support en container software is bepalend. Wij draaien geheel op Oracle AS, OC4J, en om java5 te doen moeten we naar 10.1.2 overgaan minstends, erg leuk maar dan moet alles eerst qua backend naar de compatible versies gebracht worden. En moet de gehele OTAP straat er eerst wel mee opgezet zijn gaandeweg, en moet de development er wel mee gaan werken voor de volgende versies, ect ect etc. Dit vereist gewoon tijd.

Greenfield setups zijn natuurlijk hiervan uitgezondert, maar die zijn dan ook 'eitjes'.

Wij gebruiken vooral struts, en gaan aan de gang met Ajax.

[flowerp]

JKVA schreef op zondag 10 september 2006 @ 14:04:
[...]

Extreem flexibel is imho weer helemaal de andere kant van de waarheid. Als je zelf een StateManager moet maken omdat die van JSF niet voldoet, mankeert er toch iets aan JSF lijkt me. Het KAN, dat klopt, maar de standaard moet wel zo goed zijn dat het bijna altijd voldoet.

Uhm, maar dat zeg ik toch ook? Het voldoet bijna altijd. Normaal zou je, als gewone user, dus nooit aan die StateManager hoeven te zitten. Heb je een echt aparte use-case dan KUN je het dus anders doen en DAT maakt JSF zo flexibel.

Dat doet het ook wel redelijk, maar aan de andere kant walg ik bijvoorbeeld van de gegenereerde HTML. Momenteel krijgen we in mijn huidige project HTML bestanden van megabytes over het lijntje, puur en alleen omdat JSF per-se achterlijk veel JavaScript gaat lopen genereren per hyperlinkje.

Nu haal je volgens mij toch een paar dingen door elkaar.

Ten eerste JSF produceerd helemaal nix, omdat JSF zelf een specificatie is. Mischien dat de implementatie die jij gebruikt je op dit punt niet bevalt. Omdat het een spec is kun je voor een alternatieve implementatie kiezen. JSF is nu nog erg jong, maar alle grote producenten van een Java AS zullen uiteindelijk een JSF implementatie gaan maken (al dan niet gebasseerd op een bestaande implementatie)

Ten tweede, een JSF implementatie zelf produceerd ook al geen HTML. Het JSF framework zelf is eigenlijk geheel HTML agnostic. Het zijn de (extern) aangeroepen componenten die HTML produceren. In de JSF spec zijn wel een zeer klein aantal zeer eenvoudige basis componenten opgenomen. Dit zijn eigenlijk niets meer dan JSF wrappers voor de allersimpelste HTML constructies. Nix dwingt je om deze set van componenten te gebruiken. Je kunt tegenwoordig kiezen uit een steeds groter wordende set van 3rd party componenten. Anders gezegd, een JSF applicatie zonder 1 van de componenten uit de standaard set te gebruiken is nog steeds 100% JSF.

Het feit dat jij de gegenereerde HTML niet mooi vind ligt dus absoluut niet aan JSF of aan de concepten die aan het framework ten grondslag liggen. Er zitten mischien nog wel enkele imperfecties in het geheel, maar als jij denkt dat de HTML die je in je output ziet een direct gevolg is van de manier waarop JSF werkt dan heb je het JSF concept IMHO gewoon (nog) niet goed begrepen.

Een derde punt is dat je eigenlijk niet meer naar de gegenereerde HTML zou moeten kijken. Als web applicatie programmeur is het zeer wenselijk om ten bate van een hogere productiviteit naar een hoger abstractie niveau te gaan. Als je ooit intensief desktop applicaties hebt geprogrammeerd dan weet je dat web applicaties nog steeds een hoop geneuzel is. Verworvenheden zoals statefull components, echte OO designs, event handling, etc in desktop applicaties werden in 1 keer weggegooid toen we allemaal massaal aan de web app gingen.

In zekere zin is HTML de assembly van het web. Leuk om daar in den begin dagen mee gerommeld te hebben, maar het is toch echt tijd om een stap verder te gaan. Vroeger had je assembly programmeurs die hun neus ophaalde van de code die C of C++ compilers genereerde. Die personen wilde toen in assembly blijven programeren omdat die compiler maar troep genereerde. En inderdaad, ik kan me nog herinneren dat ik in de tijd ook wel door C compilers gegenereerde code heb zitten te optimizen. Maar wie doet dat nu nog?

Een groot voordeel van de HTML genererende componenten in JSF is dat deze (als je uit een goed onderhouden lib kiest) met de tijd vanzelf betere HTML zullen gaan genereren. En dit gebeurd voor jou grotendeels helemaal gratis. Net zoals iets als GCC uit dezelfde C/C++ source steeds hoger geoptimaliseerde code is gaan genereren, zo valt het te verwachten dat de bekende JSF componenten dit ook gaan doen.

Ook vind ik achteraf dat het een vrij hoge leercurve heeft, zeker als je meer wilt dan alleen navigatie en beans, maar bijvoorbeeld ook zelf componenten, converters, etc. maken.

Dat is wel zo, maar zeker als het aantal beschikbare componenten groeit zal de doorsnee programmeur niet snel zelf een component hoeven te maken. Hoevaak maakte jij bijvoorbeeld in Gtk+ je eigen low-level widget? Wel eens geheel van de grond af aan een scroll-bar gemaakt?

Een gedeelte van de complexiteit komt nu ook uit het feit dat je voor elk JSF component een taglib handler maakt. Dit betekent tenminste 2 aparte filetjes en een hoop heen en weer gezet van variabelen. Technisch staan taglib handlers natuurlijk helemaal los van de componenten zelf, maar omdat bijna iedereen nu JSF met JSPs gebruikt ben je wel verplicht om deze extra interface voor je component te maken. Dit gedeelte kan zeker nog veel beter...

[flowerp]

Alarmnummer schreef op zondag 10 september 2006 @ 20:51:
[...]
Hij Zij bedoelt de JSE 5 functionaliteit voor timers. Met Quartz kan je cron expressies schrijven en dat kan je met de java.util.Timer en java.util.concurrent.ScheduledExecutor niet.

Ik doelde inderdaad op de Java SE functionaliteit. We hebben hier wel naar gekeken als alternatief voor Quartz, maar in het algemeen is het allemaal net wat meer low-level dan Quartz. Mischien als deze packages hadden bestaan toen men met Quartz begonnen was, dat men Quartz hiermee had bebouwt.

Zou ook kunnen zijn dat er met J2EE timers de JMS queue in combinatie met message driven beans werden bedoeld? In dat geval kan ik kort zijn; het project waarvoor we ooit begonnen waren moest draaien op alleen een servlet container, dus deze dingen hadden we niet tot onze beschikking. Ik heb er ook geen ervaring mee, dus weet niet of dit wel of niet te vergelijken is met de (eigenlijk simpele) dingen die Quartz doet.

[TukkerTweaker]

momania schreef op zondag 10 september 2006 @ 18:00:
Ik heb me nu met 2 projecten volledig op Wicket gestort en ik ben er erg tevreden mee. De uitbreidingen op het framework worden steeds completer. Ajax support is een fluitje van een cent en de templates zijn gewoon kale html's. Gegenereerde output is er bijna niet (behalve het ajax deel dan), dus de vorm en grootte van je html heb je ook helemaal zelf onder controle. Alles is dus perfect xhtml compliant.

Gewoon heerlijk OO web devven, geen lastig template werk, vrij simpel te leren (iig simpeler dan alle andere frameworks imo) en development tijd wordt drastisch verkort.

Hier kan ik het volledig mee eens zijn.
Ook in combinatie met Spring is Wicket nog steeds prima toepasbaar. Ik heb het nu in gebruik voor een aantal kleinere projecten en ga zeker voor volgende projecten wederom voor Wicket.
Verder is het ook hier Spring wat de klok slaat. Voor ons laatste project Spring Web Services toegepast wat perfect aansluit bij het securtity framework (acegi) en de overige Spring componenten.

[ Voor 9% gewijzigd door TukkerTweaker op 11-09-2006 11:32 ]

[JKVA]

flowerp schreef op maandag 11 september 2006 @ 00:17:
[...]
Uhm, maar dat zeg ik toch ook? Het voldoet bijna altijd. Normaal zou je, als gewone user, dus nooit aan die StateManager hoeven te zitten. Heb je een echt aparte use-case dan KUN je het dus anders doen en DAT maakt JSF zo flexibel.
[...]

That's true, maar ik kan me zo snel geen praktisch voorbeeld indenken dat zoiets tijd oplevert. (lees: heel veel geld kost)

Nu haal je volgens mij toch een paar dingen door elkaar.

Ten eerste JSF produceerd helemaal nix, omdat JSF zelf een specificatie is. Mischien dat de implementatie die jij gebruikt je op dit punt niet bevalt. Omdat het een spec is kun je voor een alternatieve implementatie kiezen. JSF is nu nog erg jong, maar alle grote producenten van een Java AS zullen uiteindelijk een JSF implementatie gaan maken (al dan niet gebasseerd op een bestaande implementatie)

Ook waar, maar ik doel met JSF op een willekeurige implementatie. De spec doet immers niks. In mijn geval is dit dus MyFaces 1.1.2.

Ten tweede, een JSF implementatie zelf produceerd ook al geen HTML. Het JSF framework zelf is eigenlijk geheel HTML agnostic. Het zijn de (extern) aangeroepen componenten die HTML produceren. In de JSF spec zijn wel een zeer klein aantal zeer eenvoudige basis componenten opgenomen. Dit zijn eigenlijk niets meer dan JSF wrappers voor de allersimpelste HTML constructies. Nix dwingt je om deze set van componenten te gebruiken. Je kunt tegenwoordig kiezen uit een steeds groter wordende set van 3rd party componenten. Anders gezegd, een JSF applicatie zonder 1 van de componenten uit de standaard set te gebruiken is nog steeds 100% JSF.

Het feit dat jij de gegenereerde HTML niet mooi vind ligt dus absoluut niet aan JSF of aan de concepten die aan het framework ten grondslag liggen. Er zitten mischien nog wel enkele imperfecties in het geheel, maar als jij denkt dat de HTML die je in je output ziet een direct gevolg is van de manier waarop JSF werkt dan heb je het JSF concept IMHO gewoon (nog) niet goed begrepen.

Een derde punt is dat je eigenlijk niet meer naar de gegenereerde HTML zou moeten kijken. Als web applicatie programmeur is het zeer wenselijk om ten bate van een hogere productiviteit naar een hoger abstractie niveau te gaan. Als je ooit intensief desktop applicaties hebt geprogrammeerd dan weet je dat web applicaties nog steeds een hoop geneuzel is. Verworvenheden zoals statefull components, echte OO designs, event handling, etc in desktop applicaties werden in 1 keer weggegooid toen we allemaal massaal aan de web app gingen.

lol, ik ben het in theorie steeds met je eens, maar praktisch gezien in dit geval wederom niet. In mijn huidige project moeten we dus overzichten genereren van etterlijke 100-en regels lang. (ja, dat moet) Hier moet vanalles op komen te staan en het werkt prima, tot we commandLinks neerleggen. Die leggen namelijk ook een berg JavaScript in de pagina, waardoor het geheel ontzettend groot wordt. -> en dus traag -> en dus voldoen we niet aan de niet-func specs. In dit geval moeten we dus toch naar de gegenereerde "bende" kijken om het op te lossen. Is overigens nog niet gebeurd...

[...]
Een gedeelte van de complexiteit komt nu ook uit het feit dat je voor elk JSF component een taglib handler maakt. Dit betekent tenminste 2 aparte filetjes en een hoop heen en weer gezet van variabelen. Technisch staan taglib handlers natuurlijk helemaal los van de componenten zelf, maar omdat bijna iedereen nu JSF met JSPs gebruikt ben je wel verplicht om deze extra interface voor je component te maken. Dit gedeelte kan zeker nog veel beter...

Dat klopt helemaal. Het zijn JUIST die paar extra bestanden die voor fouten zorgen. Facelets biedt hier bijvoorbeeld een mooi alternatief. Deze zoekt namelijk alles zelf uit.

[JKVA]

ReLight schreef op zondag 10 september 2006 @ 21:06:
#Balusc "We zijn er veel met Maven 2 bezig. De ontwikkelstraat draait er namelijk op. Dit wordt ondersteund doordat we iemand hebben met zeer veel Maven 2 ervaring. Zit bij Apache en dergelijke.
"

Hoe bevalt dit ? Wij hebben echt een erg groot Ant build deploy systeem waar zo te vergelijken alles wat Maven nu bied uitgewerkt is in eigen taskdefs, extensions en macrodefs. Dit is een 3 laags systeem met developers, buildserver(s) en als laatste een samenstelling aangezien ons product als geheel gedeployed wordt uit 1 gemeenschappelijk platform + n applicaties.
Ik zie de voordelen niet echt in van Maven2 als ik erg veel moeite moet doen om toch weer afwijkingen van het ge-eikte erg omslachtig moet gaan (laten) maken. (ben zelf geen java-dev, maar kan wel goed met ant overweg).

Ik vind het tot nu toe niet super, maar wij zijn het eerste "echte" project dat ermee werkt en daardoor zaten er in het begin nog wat bugs in, maar je merkt dat het steeds volwassener wordt. Maven 1 ken ik niet, maar ik hoor regelmatig dat 2 stukken beter is.

Verder weet ik niet veel van Maven ofzo. Ik roep gewoon de scriptjes steeds aan en het werkt wel./ Bij problemen is het toch meestal de schuld van het netwerk, code, unit tests, o.i.d.

Beheer van je dependencies werkt echter wel weer heel goed, dat kan ik wel vertellen. Gewoon kwestie van POM aanpassen en hij gaat files leechen.

[Verwijderd]

Wij gebruiken nu voornamelijk JSF voor nieuwe dingen. De flexibiliteit is inderdaad behoorlijk groot. Net zoals Eclipse kun je bijna overal wel op in pluggen. In onze situatie moeten we echter, binnen in 1 project, interfacen met een aantal pagina's die 'good old' JSP/JSTL zijn. Dit betekent dat we veel linken naar JSF pagina's met get parameters (of posts, maar in iedergeval als non-faces request) en dat we andersom vanaf JSF pagina's moeten linken naar bestaande pagina's.

De support hiervoor in JSF is niet super goed. Het is niet moeilijk om er zelf wat support voor in te bouwen, maar gezien het feit dat me dit toch wel een common-case lijkt, is het wel jammer. Voorderest erg tevreden dus over JSF.

Seam wil ik zeker nog gaan bekijken. Zeker de extended contexts klinken interesant. Het belooft veel typische web problemen op te lossen. Ook zou er iets van een business model context in zitten wat je weer direct kan koppelen aan je conversatie context. Klinkt allemaal nog wat abstract en ik hoop het binnenkort voor mezelf wat concreter te krijgen

[JKVA]

Verder nog mensen met ervaringen/meningen? Ben wel benieuwd, aangezien J2EE zo veel frameworks kent...

[Verwijderd]

Ben ook wel benieuwd naar meer verhalen over wat mensen gebruiken. Mischien zou een poll in de openings post ook niet verkeerd staan

Het lijkt er dus op dat de meeste mensen toch op JSF aan het standaardiseren zijn? Maar zelfs dan is het nog interesant om te weten wat anderen gebruiken. Eigenlijk is zeggen dat je JSF gebruikt binnenkort (en nu al een beetje) bijna net zoiets als zeggen dat je Java gebruikt. Je kunt dingen vragen als welke JSF implementatie? Welke component set of sets, welke extensions, welke templating techniek, etc.

Hoewel je het mischien niet direct onder Java EE kunt scharen, zijn we nog een beetje aan het kijken wat we allemaal met Lucene kunnen doen, en hoe het met JSF te integreren is.

[JKVA]

Ik denk dat het bij ons overigens niet lang duurt tot EJB 3.0 gestandaardiseerd is. Er is nog niet erg veel kennis van, tenminste niet verspreid over het bedrijf, maar het oogt zeker wel sweet.

Zeker met Seam ertussen en JSF erboven is dat volgens mij een prima basis stack met tig mogelijkheden, maar die toch lekker weg progt.

Over JSF. Ik werk nu denk ik ongeveen een half jaar met Facelets en wil niet meer zonder. Lekker templaten, veelgebruikte stukken pagina in een component wegwerken... In één woord ideaal.
Ik ben al wel aan het kijken naar wat JSF 1.2 oplost en tegelijk naar Shale, want dat oogt ook wel lekker. Allemaal van die kleinigheidjes die in MyFaces 1.x irritant zijn, zouden dan opgelost moeten zijn. SiteMesh lijkt me ook wel een leuke templating engine, maar die heb ik zelf nog niet geprobeerd. Weet ook niet wat het met JSF doet.

Ook ADF Faces moet ik nog eens naar kijken, maar het komt er steeds niet van.

[Verwijderd]

JKVA schreef op zaterdag 16 september 2006 @ 17:38:
Ik ben al wel aan het kijken naar wat JSF 1.2 oplost en tegelijk naar Shale, want dat oogt ook wel lekker. Allemaal van die kleinigheidjes die in MyFaces 1.x irritant zijn

Ja dat klopt, in Myfaces 1.x (die dus de preview versie van JSF implementeerd) zitten van die dingetjes die opzich nix voorstellen, maar net niet 'af' zijn. Voor een preview is dat natuurlijk ook wel te verwachten, maar toch.

Paar van de kleine dingetjes zijn bijvoorbeeld het feit dat de standaard validators en converters geen mogelijkheid hebben om de naam van het component weer te geven. Ze geven standaard de ID weer, maar die is zeker in een I18N omgeving 0.0% van toepassing. Je kunt de message wel overriden en dan helemaal geen ID of naam weergeven, maar dat is toch ook niet wat je wilt. Het zal niet meer dan 10 regels code gekost hebben, maar in JSF 1.2 is dit dus gefixt.

Een andere kleinigheidje is dat je in JSF 1.x een viewhandler alleen globaal kunt defineren. In JSF 1.2 kan dat ook per pagina. Andersom kun je een resource bundle dan weer globaal defineren (net zoals je een managed bean defineerd zeg maar), terwijl dat nu alleen per pagina kan.

Veel puntjes op de i dus en de meeste dingen zijn te triviaal om echt in van die 'what's new' lijstje genoemd te worden. Kom je dus pas achter als je echt er mee werkt denk ik.

Ook ADF Faces moet ik nog eens naar kijken, maar het komt er steeds niet van.

Die hoor ik ook vaak langskomen. MyFaces is er al een tijdje mee bezig om het samen te laten werken met de rest van de components. Het is ook hernoemd zodat het kwa naam niet meer aan Oracle doet denken (dit weer om te voorkomen dat er gebeurd wat je hier ziet: zodra mensen horen dat iets van een grote organisatie komt noemen ze het meteen log en bloated, zonder het ook maar een moment bekeken te hebben). De nieuwe naam (trinidad) sluit mooi aan bij het andere components project van MyFaces (tobago).