[Java] Keuze voor JSF

vrijdag 26 oktober 2007 10:59

Carpe diem

Wij hebben hier op werk ook te maken met Websphere + JSF. IBM heeft geen JSF implementatie, het biedt slechts een component library aan. Het maakt in wezen dus niet uit welke JSF implementatie je gebruikt, zolang het de JSF spec goed volgt.

Wij gebruiken hier Sun JSF Reference Implementation 1.1 in combinatie met enkele IBM componenten (alleen de odc:tabbedPanel en hx:fileupload worden gebruikt, de rest is de moeite niet waard) en een groot deel aan custom componenten.

Websphere 5.x wordt standaard geleverd met Sun JSF RI 1.0, die kun je prima vervangen door RI 1.1. We hadden liever RI 1.2, maar die werkt alleen icm JDK 1.5 of nieuwer en Websphere 5.x leunt op JDK 1.4, waarvan wij de IBM's implementatie gebruiken.

Het voordeel van custom componenten is dat je zelf ook de opzet, layout en style direct kunt renderen en het de uiteindelijke JSF code zeer compact maakt en de webappdevelopment zeer bespoedigt. Dit is alleen nuttig als je een relatief groot aantal webapplicaties moet bouwen die dezelfde styleguide moeten volgen. Elke custom tag kan dan 5 à 10 standaard JSF RI tags vervangen (bijv: label, plaatje, infoknopje, required asterisk, invoerveld, foutmeldingveld in 1 component met 1 à 3 attributen).

[ Voor 4% gewijzigd door BalusC op 26-10-2007 10:11 ]

Acties:

vrijdag 26 oktober 2007 11:00

Carpe Diem!

Topicstarter

NetForce1 schreef op vrijdag 26 oktober 2007 @ 09:32:
Zonder inhoudelijk op je post in te gaan (ik heb nul ervaring met JSF) wil ik je toch nog even wijzen op het Echo framework (omdat je ook GWT overweegt). Persoonlijk vind ik dat een erg fijn framework, zie hier voor een comparison: http://www.theserverside.com/news/thread.tss?thread_id=40804 (wel door de ontwikkelaar van Echo).

Ik wil niet nog meer frameworks gaan opnemen. Ik ken Echo2 wel, heb er zelfs ooit een project mee gedaan.. maar toch ga ik deze niet overwegen.

BalusC schreef op vrijdag 26 oktober 2007 @ 10:00:
Wij hebben hier op werk ook te maken met Websphere + JSF. IBM heeft geen JSF implementatie, het biedt slechts een component library aan. Het maakt in wezen dus niet uit welke JSF implementatie je gebruikt, zolang het de JSF spec goed volgt.

Wij gebruiken hier Sun JSF Reference Implementation 1.1 in combinatie met enkele IBM componenten (alleen de odc:tabbedPanel en hx:fileupload worden gebruikt, de rest is de moeite niet waard) en een groot deel aan custom componenten.

Waarom gebruik je de RI en niet een opensource oplossing zoals myfaces oid?

Websphere 5.x wordt standaard geleverd met Sun JSF RI 1.0, die kun je prima vervangen door RI 1.1. We hadden liever RI 1.2, maar die werkt alleen icm JDK 1.5 of nieuwer en Websphere 5.x leunt op JDK 1.4, waarvan wij de IBM's implementatie gebruiken.

Het voordeel van custom componenten is dat je zelf ook de opzet, layout en style direct kunt renderen en het de uiteindelijke JSF code zeer compact maakt en de webappdevelopment zeer bespoedigt. Dit is alleen nuttig als je een relatief groot aantal webapplicaties moet bouwen die dezelfde styleguide moeten volgen. Elke custom tag kan dan 5 à 10 standaard JSF RI tags vervangen (bijv: label, plaatje, infoknopje, required asterisk, invoerveld, foutmeldingveld in 1 component met 1 à 3 attributen).

Wil je dan zeggen dat je geen controle hebt over layout/styling met standaard componenten?

Acties:

vrijdag 26 oktober 2007 13:01

Carpe diem

-FoX- schreef op vrijdag 26 oktober 2007 @ 10:59:
Waarom gebruik je de RI en niet een opensource oplossing zoals myfaces oid?

RI is ook opensource.

Wil je dan zeggen dat je geen controle hebt over layout/styling met standaard componenten?

Nee.

Voorbeeldje met standaard componenten:

Java Server Faces:

<h:form>
    <h:panelGrid columns="2" columnClasses="labelcolumn, inputcolumn">
        <h:panelGroup>
            <h:outputLabel value="#{msg.input1label}" for="input1" />
            <h:outputText value="*" />
            <h:graphicImage value="info.gif" title="#{msg.input1info}" styleClass="info" />
        </h:panelGroup>
        <h:panelGroup>
            <h:inputText id="input1" value="#{myBean.input1}" styleClass="input" required="true" />
            <h:message for="input1" styleClass="errorMessage" />
        </h:panelGroup>

        <%-- herhaal bovenstaand voor andere invoervelden --%>

        <h:panelGroup />
        <h:panelGroup>
            <h:commandButton value="#{msg.buttonSubmit}" action="#{myBean.submit}" styleClass="button" />
            <h:commandButton value="#{msg.buttonReset}" action="#{myBean.reset}" styleClass="button" />
            <h:commandButton value="#{msg.buttonCancel}" action="#{myBean.cancel}" styleClass="button" />
        </h:panelGroup>
    </h:panelGrid>
</h:form>

Met custom componenten kun je dat als volgt oplossen:

Java Server Faces:

<my:form bean="myBean" actions="submit, reset, cancel">
    <my:input property="input1" required="true" />

    <%-- herhaal bovenstaand voor andere invoervelden --%>
</my:form>

[ Voor 72% gewijzigd door BalusC op 26-10-2007 11:12 ]

Acties:

vrijdag 26 oktober 2007 13:09

Design-by-buzzword fanatic

BalusC schreef op vrijdag 26 oktober 2007 @ 11:00:
[...]
RI is ook opensource.
[...]
Nee.

Voorbeeldje met standaard componenten:

Java Server Faces:

<h:form>
    <h:panelGrid columns="2" columnClasses="labelcolumn, inputcolumn">
        <h:panelGroup>
            <h:outputLabel value="#{msg.input1label}" for="input1" />
            <h:outputText value="*" />
            <h:graphicImage value="info.gif" title="#{msg.input1info}" styleClass="info" />
        </h:panelGroup>
        <h:panelGroup>
            <h:inputText id="input1" value="#{myBean.input1}" styleClass="input" required="true" />
            <h:message for="input1" styleClass="errorMessage" />
        </h:panelGroup>

        <%-- herhaal bovenstaand voor andere invoervelden --%>

        <h:panelGroup />
        <h:panelGroup>
            <h:commandButton value="#{msg.buttonSubmit}" action="#{myBean.submit}" styleClass="button" />
            <h:commandButton value="#{msg.buttonReset}" action="#{myBean.reset}" styleClass="button" />
            <h:commandButton value="#{msg.buttonCancel}" action="#{myBean.cancel}" styleClass="button" />
        </h:panelGroup>
    </h:panelGrid>
</h:form>

Met custom componenten kun je dat als volgt oplossen:

Java Server Faces:

<my:form bean="myBean" actions="submit, reset, cancel">
    <my:input property="input1" required="true" />

    <%-- herhaal bovenstaand voor andere invoervelden --%>
</my:form>

Ik denk dat je de keuze voor JSF af moet laten hangen van de eisen die je hebt en of de bestaande libraries/toolkits daarop aansluiten.

JSF KAN heel snel werken, maar als je geen component libraries heb voor jouw situatie, of bepaalde flows o.i.d. zijn lastig te maken, dan moet je niet voor JSF kiezen. De kracht van JSF zit voornamelijk in het feit dat je bestaande componenten kunt hergebruiken.

Componenten maken kan ook nuttig zijn, maar vergis je niet, componenten bouwen is niet gemakkelijk en zeker als je complexere componenten wilt maken (die interactie op elkaar hebben, AJAX, etc) kan het lastig zijn.

Kijk gewoon eens naar frameworks zoals Seam, Shale, Trinidad, Ajax4jsf, Facelets, enz. Zo ben ik weleens in de val gelopen dat ik een Facelets/Trinidad/Ajax4jsf stack wilde maken. In theorie zou dat ook al mijn problemen oplossen. 1 probleempje, Trinidad en Ajax4jsf werken niet samen. Schijnbaar een known error die ze allebei op elkaar afschuiven om te fixen. Zulke integratieproblemen moet je van te voren in kaart brengen.
Hetzelfde geldt voor Facelets. Facelets is een mooi lightweight framework, maar niet IDE friendly. Gevolg, weinig IDE's met code completion in Facelets XHTML pagina's, enz.

Momenteel, zonder iets van context te kennen, zou ik Seam aanraden. Dan krijg je een mooi conversatiemechanisme out of the box, wat het naar mijn idee grootste probleem van JSF oplost, navigatie en state tussen pagina's. Eventueel kun je EJB 3.0 vervangen door Spring. Daar staat een artikel over op Developerworks.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

vrijdag 26 oktober 2007 14:56

Carpe diem

JKVA schreef op vrijdag 26 oktober 2007 @ 13:01:
Componenten maken kan ook nuttig zijn, maar vergis je niet, componenten bouwen is niet gemakkelijk en zeker als je complexere componenten wilt maken (die interactie op elkaar hebben, AJAX, etc) kan het lastig zijn.

Als je dat onder de knie hebt, levert het alleen maar voordelen op.

Momenteel, zonder iets van context te kennen, zou ik Seam aanraden.

Volledig mee eens

Thuis heb ik ook ermee zitten spelen, zit erg gaaf in elkaar. Maar ik vraag me af of dit op Websphere environment met JDK 1.4 gaat werken

Acties:

vrijdag 26 oktober 2007 15:05

Design-by-buzzword fanatic

BalusC schreef op vrijdag 26 oktober 2007 @ 13:09:
[...]
Als je dat onder de knie hebt, levert het alleen maar voordelen op.
[...]
Volledig mee eens Thuis heb ik ook ermee zitten spelen, zit erg gaaf in elkaar. Maar ik vraag me af of dit op Websphere environment met JDK 1.4 gaat werken

Hehe, vast niet nee. Ik hoop voor de TS dat hij minimaal WAS 6.1 draait.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

zaterdag 27 oktober 2007 12:35

Carpe Diem!

Topicstarter

Nee, WAS 6.0.2

Maar Seam zie ik niet goed zitten om te introduceren, eerder om politieke redenen. Er is voor WebSphere als platform gekozen, en dat was een strategische beslissing. Seam is op en top een JBoss product, dus dat ligt altijd sowieso wel lastiger.

Ik moet er misschien nog wel bijvertellen dat de schermen die ontwikkeld moeten worden helemaal niet zo complex zijn. Het gaat om list-screens (met paging, sortering, ...) en edit-screens van deze items. Veel complexer is het eigenlijk niet. De workflow op zich wordt afgehandeld door een BPM oplossing.

[ Voor 36% gewijzigd door -FoX- op 26-10-2007 21:15 ]

Acties:

zaterdag 27 oktober 2007 16:09

Design-by-buzzword fanatic

-FoX- schreef op vrijdag 26 oktober 2007 @ 15:05:
Nee, WAS 6.0.2

Maar Seam zie ik niet goed zitten om te introduceren, eerder om politieke redenen. Er is voor WebSphere als platform gekozen, en dat was een strategische beslissing. Seam is op en top een JBoss product, dus dat ligt altijd sowieso wel lastiger.

Ik moet er misschien nog wel bijvertellen dat de schermen die ontwikkeld moeten worden helemaal niet zo complex zijn. Het gaat om list-screens (met paging, sortering, ...) en edit-screens van deze items. Veel complexer is het eigenlijk niet. De workflow op zich wordt afgehandeld door een BPM oplossing.

Als je een fancy GUI wilt hebben, kun je met JSF wel een vliegende start maken door een bestaande component library te gebruiken zoals IceFaces of Backbase. Dan hoef je vrijwel niks te doen en heb je een best wel vette GUI.

Aan de andere kant is het pull model van JSF iets waar volgens mij iedereen in het begin moeite mee heeft.

Ik zou het gewoon proberen. JSF is en blijft een standaard en in mijn optiek is het een prima framework.

Overigens over de vragen uit je startpost:

-FoX- schreef op vrijdag 26 oktober 2007 @ 00:53:
In eerste instantie denk ik dan direct om JSF verder te gaan gebruiken, mede ook omwille van tooling support die er al is; maar die dan wel op een ander niveau te gebruiken is. Er komen dan wel direct een aantal vragen in me op. Hoe start ik hier het best mee?

Met een PoC.

Er zijn een heel aantal JSF implementaties (en versies), voor welke implementatie kies ik best? Als ik verder bouw op de standaard IBM implementatie, kan ik dan gemakkelijk gebruik maken van opensource alternatieven zoals MyFaces en ben ik ook gebonden aan JSP?
En voor welk opensource alternatief kies ik het best, m.a.w. wat is een goede blend?
Kan ik gewoon JSF 1.2 gebruiken, of gaat dit niet omwille van de IBM implementatie?

Ik dacht dat IBM geen implementatie had?

Qua terminologie is het JSF wereldje misschien wat verwarrend.
Je hebt de JSF specificatie.
Versie 1.1 is de versie die je in J2EE 1.4 kunt gebruiken.
Versie 1.2 is de versie die je in Java EE 5 kunt gebruiken. (geen WAS 6 dus)

Dan heb je implementaties van de spec, waarvan Apache MyFaces en de Sun Reference Implementation (RI) de bekendste zijn.
MyFaces is steeds de betere van de twee geweest met veel meer ontwikkeling en innovatie. De Sun RI was in versie 1.1 niet goed.
Dit is echter omgedraaid toen JSF 1.2 uitkwam. De Sun RI heeft al meer dan een jaar lang een implementatie waar dus ook verschillende patches voor zijn geweest. MyFaces daarentegen heeft een paar maanden geleden (augustus ofzo) pas een officiele release gedaan van hun implementatie.

Daarnaast is MyFaces de naam van een top level Apache project, wat inhoudt dat het subprojecten heeft, die met JSF te maken hebben, maar niet met een JSF implementatie. De eerste was Tomahawk, daarna zijn er nog Tobago, Trinidad en Orchestra bijgekomen. En binnenkort komt er een update bij van Trinidad (die wel echt AJAX is). Tenslotte wordt momenteel gespeculeerd of Shale een subproject van MyFaces wordt.

Vanaf JSF 2.0 zal er support zijn voor facelets, maar ik zou het nu al graag willen gebruiken? Kan dat zonder al teveel potten te breken? Hoe zou het zitten met latere migratie?

Wat je zegt is niet helemaal correct. In JSR 314 (http://jcp.org/en/jsr/detail?id=314), de JSR voor JSF 2.0, wordt gezegd dat er een vorm van templating gestandaardiseerd wordt. Ook wordt Facelets genoemd, maar ook Tiles en JSFTemplating worden genoemd. Ik verwacht dus dat het uiteindelijke resultaat niet 100% Facelets zal zijn.

Daarnaast ben ik persoonlijk een beetje uitgekeken op Facelets. Ik gebruik het nu ongeveer 1,5 jaar en dat is 1,5 jaar zonder fatsoenlijke IDE support (code completion, validatie) geweest. Ikzelf heb er niet meer zoveel problemen mee, aangezien je op den duur de attributen wel uit je hoofd kent, maar mijn projectleden hebben er zwaar veel last van. Bovendien lijkt het erop dat we nog wel ff moeten wachten op fatsoenlijke IDE support, aangezien het aan de werking van Facelets ligt. Het is erg moeilijk om IDE support voor Facelets te maken.

(het programmeermodel van Facelets vind ik overigens nog steeds prachtig)

Er zijn wel tamelijk wat resources online te vinden over JSF, maar ze lijken me allemaal redelijk droog. In de zin van "zo kan je het gebruiken", en niet in de zin van "zo kan je JSF het bést gebruiken", met een aantal best practices en een meer pragmatische aanpak. Ook zijn er al verschillende resources verouderd.
Waar kan ik best starten (als ik er totaal niets van zou afweten, maar ook echt niets )? Ik wil niet zelf gaan ondervinden wat nu eigenlijk de beste manier is, na een aantal weken/maanden, ik wil er gelijk goed mee van start kunnen.

Er zijn een aantal zaken waar je op moet lettten.
- Het eerste is dat je heel bewust moet zijn van het pullmodel. Dat is een wezenlijk verschil met request based frameworks. Dus niet: "Ik vul in een action een map met properties en die lees ik in de pagina uit", maar "Ik leg componenten op de pagina en die halen hun data ergens vandaan. I don't care how.".
- Daarnaast, zorg gewoon voor nette code. JSF biedt een heel aantal hooks om een soort AOP voor elkaar te krijgen, met PhaseListeners, ActionListeners, enz. Bovendien kun je alle core onderdelen vervangen. Spring vervangt bijvoorbeeld de VariableResolver door een Spring variant die hetzelfde doet, maar daarnaast ook Spring beans kan inladen. Een ActionListener kun je prima gebruiken voor het afvangen van fouten uit je methoden.
- Probeer je zoveel mogelijk aan de spec te houden. Pageflow scopes, skinning, partial page refresh en specifieke renderers zijn erg leuk, maar zorgen ook voor een vendor lock-in. Kijk altijd of frameworks daadwerkelijk integreren. Dat is ook een afweging om Facelets wel/niet te gebruiken.
- Zet niet alles in één faces-config bestand, maar splits deze op in meerdere bestanden. Use case of subsysteem is doorgaans wel een goede opsplitsing.

XML:

<context-param>
  <param-name>javax.faces.CONFIG_FILES</param-name>
  <param-value>/WEB-INF/faces-config/1.xml,/WEB-INF/faces-config/2.xml</param-value>
</context-param>

Maar vooral, wees jezelf bewust van het pullmodel, anders krijg je voor je het weet allemaal getters met logica, zoals hieronder.

Java:

public class SessionScopedManagedBean {
    private List list;

    public List getPeople() {
        if (list == null) {
            list = peopleService.findAllPeople();
        }
        return list;
    }
}

Wat doe ik met de bestaande (gegenereerde) schermen, begin ik van scratch met een opensource implementatie? Nu kan het eventueel nog

Implementatie zou niet boeiend moeten zijn. Je container levert zelf ook libraries mee en die hebben sowieso voorrang qua classloading. In WebSphere 6 (of 6.1, ik weet het niet meer precies) wordt in ieder geval de Sun RI gebruikt, zelfs al package je zelf MyFaces mee.

Veel vragen omdat er voor mij nog veel onduidelijkheid is blijkbaar. Ik denk dat dit gelijkertijd ook het grote probleem is om met JSF te starten, het is niet echt duidelijk waar er precies gestart moet worden.. er is zoveel! JSP is JSP, Servlets zijn Servlets en Struts was Struts ( ).. bij JSF hebben we een set van implementaties, libraries, componenten.

Ik hoor ook graag ervaringen als iemand in een gelijkaardige situatie gezeten heeft (IBM omgeving en web framework development behalve Struts

Bij een vorig project hebben we JSF 1.1 gebruikt in WebSphere 6(.1), maar niet met een IBM IDE. We gebruikten toen MyEclipse. JSF werkte prima, vrijwel geen problemen mee gehad, maar ik had al eerder met JSF gewerkt en dus al wat ervaringen opgedaan.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

zaterdag 27 oktober 2007 17:09

Design-by-buzzword fanatic

Kleine update, ik zie zojuist een apart bericht:
http://www.caucho.com/press/2007-10-07.xtp

Wel apart. Een implementatie, terwijl de spec nog niet af is...

Fat Pizza's pizza, they are big and they are cheezy

Acties:

zondag 28 oktober 2007 13:36

Carpe Diem!

Topicstarter

Bedankt voor het uitgebreide overzicht. Qua implementatie lijkt het me dan gewoon het best om de SUN RI 1.1 te volgen.. standaard meegeleverd. Het is idd de Sun implementatie, maar aangezien deze in een ibm-impl.jar zit, was het even verwarrend

Probleem is dat er momenteel een JSF applicatie bestaat, die eigenlijk lang niet af is (geen validatie, messages, resourcebundles, ...); en ze vinden deze app dus ook bijzonder lelijk. Het IT team daar heeft geen kaas gegeten van JSF development (of van eender welk ander Java framework); maar wil wel de mogelijkheid hebben om aanpassingen aan de pagina's te kunnen doorvoeren.

Ik twijfel nog altijd erg of ik JSF (voor mij ook "nieuw") zou gebruiken. Uiteindelijk wel leuk voor me, aangezien ik dan weer iets nieuws kan bijleren; alleen hoop ik dan wel snel productief te zijn. Ofwel het toch gewoon houden op SpringMVC, dat ik ondertussen ook wel goed ken.

Resin geval zal wel een foutje zijn, ik denk dat ze JSF 1.2 bedoelen.. aangezien ze het ook hebben als "part of JEE5".

Acties:

zondag 28 oktober 2007 17:26

Design-by-buzzword fanatic

-FoX- schreef op zaterdag 27 oktober 2007 @ 17:09:
Bedankt voor het uitgebreide overzicht. Qua implementatie lijkt het me dan gewoon het best om de SUN RI 1.1 te volgen.. standaard meegeleverd. Het is idd de Sun implementatie, maar aangezien deze in een ibm-impl.jar zit, was het even verwarrend

Probleem is dat er momenteel een JSF applicatie bestaat, die eigenlijk lang niet af is (geen validatie, messages, resourcebundles, ...); en ze vinden deze app dus ook bijzonder lelijk. Het IT team daar heeft geen kaas gegeten van JSF development (of van eender welk ander Java framework); maar wil wel de mogelijkheid hebben om aanpassingen aan de pagina's te kunnen doorvoeren.

Ik twijfel nog altijd erg of ik JSF (voor mij ook "nieuw") zou gebruiken. Uiteindelijk wel leuk voor me, aangezien ik dan weer iets nieuws kan bijleren; alleen hoop ik dan wel snel productief te zijn. Ofwel het toch gewoon houden op SpringMVC, dat ik ondertussen ook wel goed ken.

Resin geval zal wel een foutje zijn, ik denk dat ze JSF 1.2 bedoelen.. aangezien ze het ook hebben als "part of JEE5".

Aanpassingen doorvoeren aan pagina's is bij elk framework goed mogelijk, mits de code een beetje degelijk is opgezet.

Zo is bij mijn huidige klant een JSF project gedaan waar ze letterlijk om het framework heen hebben gewerkt. Geen validaties van JSF, maar een zelfgebouwd framework dat de validaties in de business logica heeft uitgevoerd.
Ook hadden ze ervoor gekozen om in plaats van ActionEvents, alleen ValueChangeEvents af te vangen. Ze dachten dat dat efficienter was. Helaas werkte het voor geen meter en zijn ze aan het hacken gegaan om te zorgen dat de ValueChangeListeners zich als ActionListeners gingen gedragen. Tel hierbij het gebrek aan Hibernate kennis op en je kunt wel raden hoe het met dat project is afgelopen...

Het is gewoon een kwestie van gezond verstand gebruiken. Verdiep je een beetje in een framework voordat je het gaat gebruiken. Probeer te achterhalen wat de gedachte van de makers was bij een bepaald onderdeel en reflecteer continu over je werk.

Ten slotte, dit is een goed boek, geschreven door DE JSF guru, Ed Burns.
http://www.amazon.com/Jav...e-Reference/dp/0072262400

Fat Pizza's pizza, they are big and they are cheezy

Acties:

flowerp

-FoX- schreef op zaterdag 27 oktober 2007 @ 17:09:
Bedankt voor het uitgebreide overzicht. Qua implementatie lijkt het me dan gewoon het best om de SUN RI 1.1 te volgen.. standaard meegeleverd.

Ik heb de hele thread (nog) niet gelezen, maar om hier even op in te haken: RI 1.1 stond als vrij slecht bekend. Iedereen gebruikte daarom ook MyFaces 1.1 in die tijd. Sun zelf zag RI 1.1 (klaarblijkelijk) echt meer als een beta of preview versie van JSF. Vanaf hun kant gezien misschien logisch; JSF zou pas met 1.2 officieel in Java komen. Er zaten veel bugs in RI 1.1, terwijl Myfaces 1.1 als een zonnetje liep.

Met JSF 1.2 was opeens alles anders. De RI was stabiel, had hoge performance en een Sun die er duidelijk mee bezig was. MyFaces wilde er echter niet in mee. Die vonden al hun andere projecten veel leuker. Na veel gezeur hebben ze morrend een jaar(!) later nog wel een 1.2 uitgebracht. Ondanks een paar echte showstopper bugs is er 3 maanden later nog geen eerste update van uitgebracht en als je op de mailinglists kijkt zijn ze er ook niet echt mee bezig.

In combinatie met facelets kun je RI 1.2 gewoon in een servlet 2.4/JSP 2.0 (J2EE 1.4) omgeving gebruiken.

ps

Boek dat JKVA aanraadt kan ik zeker ook aanraden. Geeft zowel practische informatie alsmede background (waarom zitten dingen intern zo inelkaar).

[ Voor 5% gewijzigd door flowerp op 28-10-2007 17:28 ]

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zondag 28 oktober 2007 19:12

Acties:

zondag 28 oktober 2007 20:13

Carpe diem

Er zijn wel een hele hoop bugs in RI 1.1_02 verholpen

JKVA: wat is er precies fout aan lazy loading in getters van een sessionbean? Enige nadeel is dat de data gedurende de sessie niet wordt bijgewerkt mocht de actuele data in de DB bijgewerkt worden. Je kunt in dit geval ook gewoon een requestbean gebruiken en de data via constructeur of initblock laden. Of mocht het per-se een sessionbean moeten zijn en je bij elke view verse data wilt ophalen, dan kun je ook if (facesContext.getRenderResponse()) { loadData(); } in de getter doen.

Acties:

zondag 28 oktober 2007 22:05

Design-by-buzzword fanatic

BalusC schreef op zondag 28 oktober 2007 @ 19:12:
Er zijn wel een hele hoop bugs in RI 1.1_02 verholpen

JKVA: wat is er precies fout aan lazy loading in getters van een sessionbean? Enige nadeel is dat de data gedurende de sessie niet wordt bijgewerkt mocht de actuele data in de DB bijgewerkt worden. Je kunt in dit geval ook gewoon een requestbean gebruiken en de data via constructeur of initblock laden. Of mocht het per-se een sessionbean moeten zijn en je bij elke view verse data wilt ophalen, dan kun je ook if (facesContext.getRenderResponse()) { loadData(); } in de getter doen.

Mja, het is niet zozeer een groot probleem, maar ik vind het nogal lelijk. Die if (var == null) vind ik al een aanduiding dat het niet echt netjes is.
Die getRenderResponse is wel een leuke, maar nog steeds niet echt mooi in mijn optiek.
Ik kan niet helemaal verwoorden waarom ik het niet mooi vind, maar het heeft iets met expliciete code te maken, een soort programming by side-effect. (overigens doe ik het zelf ook nog weleens

)

Constructor gaat niet altijd, aangezien die code vóór de dependency injection zit. Ik maak zelf eerst altijd een init methode. D.m.v. een interface of annotation roep ik dat ding aan vlak nadat de dependency injection geweest is. Eigenlijk het @postConstruct dat ook in Seam en Shale zit. Dat deed ik dan met een custom VariableResolver die eerst door delegeert naar de standaard resolver om daarna nog die ene methode aan te roepen.

Dat systeempje met VariableResolver werkt best wel goed eigenlijk. Aangezien je in JSF je data in 1 pagina uit tig managed beans kunt trekken, is dat volgens mij de enige plek waar je weet dat je bean geïnitialiseerd wordt. Zorg er wel voor dat je een administratie bijhoudt van welke beans wel en niet geïnitialiseerd zijn, want anders initialiseer je je bean bij elke aanroep.

Hmm, ik zie hier trouwens dat het ook in JSF 1.2 zou moeten zitten:
http://weblogs.java.net/b...7/05/jsf_12_ri_backi.html

Fat Pizza's pizza, they are big and they are cheezy

Acties:

curry684

left part of the evil twins

JKVA schreef op zondag 28 oktober 2007 @ 20:13:
[...]

Mja, het is niet zozeer een groot probleem, maar ik vind het nogal lelijk. Die if (var == null) vind ik al een aanduiding dat het niet echt netjes is.

Waarom is het niet netjes om te testen of een variabele al gezet is?

* curry684 ziet dus echt totaal geen probleem in de genoemde constructie afgezien van potentieel out-of-date data voor dit specifieke geval.

Professionele website nodig?

maandag 29 oktober 2007 07:59

Acties:

maandag 29 oktober 2007 08:07

Carpe Diem!

Topicstarter

flowerp schreef op zondag 28 oktober 2007 @ 17:26:
[...]
In combinatie met facelets kun je RI 1.2 gewoon in een servlet 2.4/JSP 2.0 (J2EE 1.4) omgeving gebruiken.

Even voor de duidelijkheid... Enkel met facelets?

Acties:

maandag 29 oktober 2007 08:17

Design-by-buzzword fanatic

-FoX- schreef op maandag 29 oktober 2007 @ 07:59:
[...]

Even voor de duidelijkheid... Enkel met facelets?

Ja, Facelets gebruikt geen JSP, dus die jars heb je niet nodig. Bovendien packaged Facelets zelf de jars voor de nieuwe EL en zo mee.

Over die ifjes, misschien is het een kwestie van smaak, maar ik vind het nogal lelijk.

Als je niet oppast, komt in elke getter van elke bean een dergelijke check te staan. Bovendien verplicht je jezelf om session scoped beans te gebruiken in het geval van datatables, omdat anders zowel bij het laden als bij het klikken op een link de data geladen wordt.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

maandag 29 oktober 2007 08:30

Carpe Diem!

Topicstarter

JKVA schreef op maandag 29 oktober 2007 @ 08:07:
[...]

Ja, Facelets gebruikt geen JSP, dus die jars heb je niet nodig. Bovendien packaged Facelets zelf de jars voor de nieuwe EL en zo mee.

Ik ben toch niet zo'n voorstander om dan Facelets te gaan gebruiken, gezien de tooling support het nogal laat afweten blijkbaar. Zeker omdat het niet in huidige vorm in de standaard terecht zal komen.

Maar als ik het goed begrijp, kan het JSF 1.2 niet met JSP gebruikt worden? JSP 2.0 zit toch al standaard in J2EE 1.4

Acties:

maandag 29 oktober 2007 08:44

Carpe diem

JSF 1.2 vereist idd JSP 2.1. Ik heb geen ervaring met Facelets tho.

JKVA schreef op maandag 29 oktober 2007 @ 08:07:
Over die ifjes, misschien is het een kwestie van smaak, maar ik vind het nogal lelijk.

Als je niet oppast, komt in elke getter van elke bean een dergelijke check te staan.

Kwestie van smaak dus

Bovendien verplicht je jezelf om session scoped beans te gebruiken in het geval van datatables, omdat anders zowel bij het laden als bij het klikken op een link de data geladen wordt.

Dat kan ook prima anders. Gewoon de data 1x laden in constructor/initblock en bij elke save/update/delete de data herladen, of misschien zelfs bij elke view mbv de FacesContext#getRenderResponse() check in de getter. Datatables kunnen overigens ook gebruikt worden met request scoped beans.

[ Voor 4% gewijzigd door BalusC op 29-10-2007 08:33 ]

Acties:

maandag 29 oktober 2007 08:56

Design-by-buzzword fanatic

BalusC schreef op maandag 29 oktober 2007 @ 08:30:
[...]
Dat kan ook prima anders. Gewoon de data 1x laden in constructor/initblock en bij elke save/update/delete de data herladen, of misschien zelfs bij elke view mbv de FacesContext#getRenderResponse() check in de getter. Datatables kunnen overigens ook gebruikt worden met request scoped beans.

Je kunt ze idd gebruiken, maar bij een actionevent in de datatable wordt de getter opnieuw aangeroepen. Als het een getter op een request scoped bean is, is die property weer null dus moet je weer bijv naar de database.

Die optie met getRenderResponse() klinkt valide, maar ik ben benieuwd of het ook in het datatable verhaal werkt, aangezien de getter dan tijdens het actionevent een nullwaarde/lege lijst teruggeeft. Vind de lifecycle dat leuk? Als dat werkt, klinkt het als een goede fix.

Fat Pizza's pizza, they are big and they are cheezy

Acties: