[JSF] Navigatie is stuk..

[Standeman]

Volgens de tutorials zou het moeten werken, maar ik krijg het niet voor elkaar. Ik wil met een commandbutton wat code uitvoeren en dan navigeren naar een andere pagina. Het klinkt o zo simpel:
jsp:

Java:

<ice:commandButton 
    action="#{cardIssuerListBean.create}" 
    value="Create" />

bean:

Java:

    public String create() {
        this.selectedCardIssuer = new TokenIssuer();
        return "create";
    }

faces-config.xml

XML:

    <navigation-rule>
        <display-name>issuer_overview</display-name>
        <from-view-id>/issuer_overview.jspx</from-view-id>
        <navigation-case>
            <from-action>
                #{cardIssuerListBean.create}
            </from-action>
            <from-outcome>create</from-outcome>
            <to-view-id>/cardissuer.jspx</to-view-id>
        </navigation-case>
    </navigation-rule>

Wanneer ik op de knop klik wordt de methode wel uitgevoerd, maar gebeurt er verder niets met navigatie.

de specs van mijn omgeving:
* JSF1.1 sun ref impl
* Icefaces
* Tomcat 5.5.23

Iemand enig idee wat ik fout doe?

[JKVA]

Ehm, dit klinkt niet IceFaces specifiek. Tenminste, ik neem aan dat je geen specifieke NavigationHandler gebruikt? Let op, die navigationhandler kan ook in een [jarfile]/meta-inf gedefinieerd zijn, want die worden automatisch ingeladen.

Het enige wat ff in me opkomt is dat je viewid niet /issuer_overview.jspx is...

[Standeman]

JKVA schreef op donderdag 19 juli 2007 @ 10:27:
Ehm, dit klinkt niet IceFaces specifiek. Tenminste, ik neem aan dat je geen specifieke NavigationHandler gebruikt? Let op, die navigationhandler kan ook in een [jarfile]/meta-inf gedefinieerd zijn, want die worden automatisch ingeladen.

Het enige wat ff in me opkomt is dat je viewid niet /issuer_overview.jspx is...

Ik denk ook niet dat IceFaces er iets mee te maken heeft. Ik wilde gewoon compleet zijn.
Verder gebruik ik geen specifieke NavigationHandler en de meta-inf is zo goed als leeg.

Die /issuer_overview.jspx zou wel moeten kloppen, ik heb de WTP editor gebruikt om de faces-config.xml te maken.

Bedenk opeens wat... in mijn index.jsp forward ik naar issuer_overview.iface. Misschien dat dat er iets mee te maken heeft.. even proberen.

[BalusC]

De viewid's zouden ongemapte URL's moeten zijn, dus niet 'alvast' voorbereid voor de facesservlet. Ik gok dat de bestanden in de werkelijkheid de *.jsp extensie hebben en dat je de facesservlet hebt gemapped op *.jspx. In dit geval moet je de viewId's hernoemen van *.jspx naar *.jsp.

De from-view-id moet in ieder geval dezelfde zijn als

Java:

String fromViewId = FacesContext.getCurrentInstance().getViewRoot().getViewId();

in de create() methode.

[Standeman]

BalusC schreef op donderdag 19 juli 2007 @ 10:38:
De viewid's zouden ongemapte URL's moeten zijn, dus niet 'alvast' voorbereid voor de facesservlet. Ik gok dat de bestanden in de werkelijkheid de *.jsp extensie hebben en dat je de facesservlet hebt gemapped op *.jspx. In dit geval moet je de viewId's hernoemen van *.jspx naar *.jsp.

De from-view-id moet in ieder geval dezelfde zijn als

Java:

String fromViewId = FacesContext.getCurrentInstance().getViewRoot().getViewId();

in de create() methode.

De bestanden hebben wel een .jspx extensie (i.v.m. IceFaces), dus verkeerd gegokt. Echter, ze worden wel gemapt op .iface.

Dus:

code:

<from-view-id>/issuer_overview.iface</from-view-id>

werkt wel.

[BalusC]

Standeman schreef op donderdag 19 juli 2007 @ 10:50:
Dus:

code:

<from-view-id>/issuer_overview.iface</from-view-id>

werkt wel.

Dus je probleem is opgelost?

Welja, vreemd dat het met de mapped URL wél werkt. IceFaces zal wel weer het een en ander aan de NavigationHandler hebben gesleuteld.

Wat zegt de ViewRoot#getViewId() trouwens in de create() methode?

[ Voor 8% gewijzigd door BalusC op 19-07-2007 11:01 ]

[Standeman]

Het probleem is idd opgelost.. Thanks BalusC en JVKA

De output van ViewRoot#getViewId() is inderdaad "/issuer_overview.iface". Ik ga even nakijken hoe het met die Navigation handler zit.

Ik geloof echter wel dat ik aan dat JSF kan gaan wennen..

[JKVA]

Standeman schreef op donderdag 19 juli 2007 @ 11:30:
Het probleem is idd opgelost.. Thanks BalusC en JVKA

De output van ViewRoot#getViewId() is inderdaad "/issuer_overview.iface". Ik ga even nakijken hoe het met die Navigation handler zit.

Ik geloof echter wel dat ik aan dat JSF kan gaan wennen..

Haha, iedereen haat JSF in het begin. Naarmate je het vaker gebruikt wordt het (op zijn minst iets) leuker.

Maar dat het met iface werkt is wel raar.

[Standeman]

Hoe zit het dan met JSF?

Stel in mijn web.xml heb ik staan:

code:

    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class> javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.jsf</url-pattern>
    </servlet-mapping>

en ik heb file foo.jsp

Kan ik dan in de navigation rules zowel foo.jsf als foo.jsp gebruiken? Ik neem aan dat foo.jsp niet door de faces servlet wordt gehaald...

[BalusC]

Bij de default RI implementatie moet je gewoon de unmapped *.jsp gebruiken in de navigationcases.

Voordeel hiervan is dat je dan de mapping op 1 plaats hoeft aan te passen. Ik kijk daarom ook erg op dat dit niet het geval is bij IceFaces.

JSF is cool, maar de 3rd party frameworks willen nogal eens roet in het eten gooien en voor verwarring zorgen. Jammer eigenlijk. * BalusC houdt het gewoon bij de RI plus custom componenten waar nodig.

[ Voor 71% gewijzigd door BalusC op 19-07-2007 12:01 ]

[Standeman]

Tja.. ik ben ook niet zo dol op van die frameworks van allerlei leveranciers.. Het klinkt vaak leuk en handig, maar soms implementeren ze zaken raar of / en is het maar half gedocumenteerd (er staat bij icefaces bijv. amper documentatie in de javadoc).

Ik hou het altijd graag bij de referentie frameworks. Maar goed, dat is niet altijd mijn beslissing (o.a. in dit geval).

[JKVA]

BalusC schreef op donderdag 19 juli 2007 @ 11:59:
Bij de default RI implementatie moet je gewoon de unmapped *.jsp gebruiken in de navigationcases.

Voordeel hiervan is dat je dan de mapping op 1 plaats hoeft aan te passen. Ik kijk daarom ook erg op dat dit niet het geval is bij IceFaces.

JSF is cool, maar de 3rd party frameworks willen nogal eens roet in het eten gooien en voor verwarring zorgen. Jammer eigenlijk. * BalusC houdt het gewoon bij de RI plus custom componenten waar nodig.

Idd, ik denk er precies hetzelfde over. Componenten zijn leuk, zoals Trinidad, maar ze hebben allemaal hun eigen eigenaardigheden en er worden complete frameworks in gebouwd, bovenop JSF. Voorbeelden hiervan zijn bijvoorbeeld de DialogManager uit Shale, het dialog framework uit Trinidad, de pageflowscope uit trinidad, etc.

Gebruik daarvan zorgt in bepaalde mate (afhankelijk van hoeveel je gebruikmaak van de features) voor een vendor lock in. Die twee dialog frameworks zijn bijvoorbeeld niet uitwisselbaar.

Daarnaast maken dergelijke grote frameworks het decorator principe van JSF lastiger, aangezien ze overal tussen willen zitten. Voorbeeld:
Facelets configureer je normaal gesproken in faces-config. Daar hoor je te bepalen welke ViewHandler je gebruikt.
Dit werkt echter niet als je Ajax4jsf gebruikt, waardoor je die configuratie niet mag gebruiken. In dat specifieke geval moet je een Ajax4jsfFilter definieren in web.xml en kun je met een context parameter aangeven dat je Facelets gebruikt.
Als je Trinidad gebruikt, moet je ook iets dergelijks doen met je web.xml.
Op zich boeit dit op het eerste gezicht niet, maar wat ga je doen als je Trinidad, Ajax4jsf en Facelets combineert? Dat wordt een hele fragiele configuratie. Ik moet het voor een klant binnenkort proberen, maar ik voorzie problemen, simpelweg omdat ze niet op een uniforme manier werken.

[Standeman]

Mij is gevraagd om JSF, IceFaces en Spring webflow te gaan combineren. Echt handig als je net in JSF aan het duiken bent

Ik ben ook erg benieuwd hoe die combinatie gaat werken (als het gaat werken). Van horen zeggen heb ik wel meegekregen dat Spring-webflow een stuk duidelijker is dan JSF navigatie. Of dat ook zo is moet ik eerst nog maar eens zien.

Het is wel lekker uitzoekwerk

[JKVA]

Standeman schreef op donderdag 19 juli 2007 @ 12:59:
Mij is gevraagd om JSF, IceFaces en Spring webflow te gaan combineren. Echt handig als je net in JSF aan het duiken bent

Ik ben ook erg benieuwd hoe die combinatie gaat werken (als het gaat werken). Van horen zeggen heb ik wel meegekregen dat Spring-webflow een stuk duidelijker is dan JSF navigatie. Of dat ook zo is moet ik eerst nog maar eens zien.

Het is wel lekker uitzoekwerk

Mwah, duidelijk is niet echt het goede woord. Het is wel veel uitgebreider en dat is fijn als je complexere flows hebt met strikte volgordes. Dus geen vrije navigatie. Daar is het overhead die je niet wil en bovendien is het traag.

De impact van Web Flow is in mijn ervaring echt veel kleiner dan van een framework zoals Trinidad, Shale of Seam omdat het alleen navigatie regelt wanneer jij dat wil.