# [jsf] Navigations- und Page-Reloadproblem



## Taste (15. Mai 2008)

Hallo, 

ich hab in meiner JSF-Anwendung das eigenartige Problem, dass die Navigation irgendwie "nicht so will ich wohl will".

Ich habe die index.html, die direkt auf eine loginPage.jsp weiterleitet. Soweit passt das auch alles. Die Navigation in meiner weiteren Anwendung funktioniert im Prinzip auch (Bis auf kleine Probleme s.u.), nur zeigt die Adresszeile des Browsers (IE7, Firefox aber auch) stets nicht die Seite auf der ich mich gerade befinde, sondern die jeweils vorherige Seite...

Kann mir das jemand erklären?



Zu den beiden Problemen:
Ich habe eine Suchmaske, mit einigen Kostrukten der folgenden Art:


```
<h:selectOneMenu value="#{arcContent.searchVersionInputfield.testIdentifier}" styleClass="searchMenuLabel" onchange="setTextfield('_idJsp0:content:b3', this.value)" >

<f:selectItems value="#{arcContent.testIdentifierItems}" />
</h:selectOneMenu>

<h:inputText id="b3" styleClass="searchTextFieldB1" value="#{arcContent.searchVersion.testIdentifier}" />
```

Das selectOneMenu wird aus der Bean mit Werten gefüllt, der Anwender wählt einen aus, welcher dann per Javascript (setTextfield(...)) in das nebenstehende Textfeld geschrieben wird.
Dann klickt der Anwender einen "Suchen"-Button:


```
<h:commandButton id="find" value="Suchen" action="#{arcNavigation.loadSearchResultPage}" />
```

wodurch dieser String ausgelöst wird:


```
public String loadSearchResultPage() { 
String action = "loadSearchResultPage";
return action;
}
```

Dies sollte durch Mapping in der faces-config.xml die Ergebnisseite laden:


```
<navigation-rule>
<navigation-case>
<from-outcome>loadSearchResultPage</from-outcome>
<to-view-id>/pages/testSearchResultPage.jsp</to-view-id>
</navigation-case>
</navigation-rule>
```

Nach dem ersten Start der Applikation funktioniert dies leider nicht, und es wird nur die Seite mit der Suchmaske neu geladen... Beim zweiten Druck auf den "Suchen"-Button, sowie bei jedem weiteren Aufruf der Suchmaske funktioniert es wie gewünscht.

Läuft die Session ab, dann das selbe Phänomen erneut...

Kann das irgendetwas mit einem Sessioncontext zu tun haben? Hat das mit oben genanntem Navigationsphänomen zu tun? Ich verstehe es wirklich nicht und weiß nicht wo ich suchen soll...

Gruß, Taste


----------



## maki (15. Mai 2008)

> nur zeigt die Adresszeile des Browsers (IE7, Firefox aber auch) stets nicht die Seite auf der ich mich gerade befinde, sondern die jeweils vorherige Seite...


Das ist ja auch i.O. so, vergiss nciht, die Addressleiste ist meist nutzlos in dynamischen Webanwedungen, da die Paramter fast immer per Post übergeben werden, ausserdem spricht man mit MVC sowieso keine JSPs direkt an.



> Nach dem ersten Start der Applikation funktioniert dies leider nicht, und es wird nur die Seite mit der Suchmaske neu geladen... Beim zweiten Druck auf den "Suchen"-Button, sowie bei jedem weiteren Aufruf der Suchmaske funktioniert es wie gewünscht.
> 
> Läuft die Session ab, dann das selbe Phänomen erneut...
> 
> Kann das irgendetwas mit einem Sessioncontext zu tun haben? Hat das mit oben genanntem Navigationsphänomen zu tun? Ich verstehe es wirklich nicht und weiß nicht wo ich suchen soll...


Nutzt du schon Facestrace (http://facestrace.sourceforge.net/)?


----------



## Terminator (15. Mai 2008)

Uff - könnt mir gar net niemals vorstellen dass Google und Konsorten Ihre Suchen mit POST umsetzen.
Ne Suche sollte immer mit GET realisiert werden, dann passt das auch mit der Adressleiste.


----------



## Taste (15. Mai 2008)

@maki:

Oh, vielen Dank für den Tipp bezüglich FacesTrace. Leider bekomme ich das Ganze noch nicht zum Laufen (Fehler gibts aber auch keine... Kannst Du mir sagen was ich verkehrt mache?

Ich hab die Anweisungen hier: http://facestrace.sourceforge.net/main/setup.html soweit befolgt, aber leider sehe ich nichts von den Traces. 

Gruß, Taste


----------



## maki (15. Mai 2008)

Terminator hat gesagt.:
			
		

> Uff - könnt mir gar net niemals vorstellen dass Google und Konsorten Ihre Suchen mit POST umsetzen.
> Ne Suche sollte immer mit GET realisiert werden, dann passt das auch mit der Adressleiste.


Google und Konsorten sind auch keine JSF Anwendungen 

GET hat Einschränkungen, wie viele Daten kann man denn shcon in der URL mitgeben?
Manche Router unterstützen bis zu 256, manche weniger, deswegen ist GET nicht zuverlässig genug für eine Suche.

POST rules *g*

Klar ist POST doof wenn es um die Suchmaschinen Indizierung geht, aber bis jetzt sollte keine meiner Anwendungen bzw. einzelne Dialoge davon per Google gefunden werden, ich halte es für die Ausnahme, zumindest aus meiner Sicht.

@Taste

In der JSP (zB im Footer) die lib einbinden:
<%@ taglib uri="http://facestrace.sourceforge.net" prefix="ft"%>

und dann nutzen:
<ft:trace />

Natürlich muss die jar im WEB-INF/lib Verzeichniss sein.

Fertig


----------



## Taste (15. Mai 2008)

@maki:

Naja, so stand das ja in der verlinkten Anleitung. Eine meiner Seiten sieht z.B. so aus:

```
<%@ page contentType="text/html; charset=UTF-8"%>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@ taglib uri="http://facestrace.sourceforge.net" prefix="ft"%>

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Cp1252" />
<link href="styles.css" rel="stylesheet" type="text/css" />
<f:loadBundle basename="messages" var="msgs" />
<title>ArchiveBrowser</title>
</head>

<body>
<f:view>
	<h:form>
		<h:panelGrid columns="1" styleClass="loginPage"
			rowClasses="navigationRow">
			<f:facet name="header">
				<f:subview id="state">
					<jsp:include page="stateArea.jsp" />
				</f:subview>
			</f:facet>

			<h:panelGrid columns="1" styleClass="loginGrid">

				<h:panelGrid columns="2" styleClass="whole"
					columnClasses="rightAligned, leftAligned" rowClasses="standardRow">
					<h:outputText styleClass="loginLabel"
						value="#{msgs.loginPage_username}" />
					<h:selectOneMenu
						value="#{arcLoginManager.userID}"
						styleClass="loginMenuLabel"
						onchange="submit()" >
						<f:selectItems value="#{arcLoginManager.userRoleItems}" />
					</h:selectOneMenu>
				</h:panelGrid>
				<h:outputText value=" " />
				<h:commandButton styleClass="button"
					value="#{msgs.loginPage_loginButton}" action="#{arcLoginManager.loginAction1}" />
				
				<h:outputText styleClass="loginLabel" value=" "/> 
				<h:panelGrid columns="3" styleClass="whole"
					columnClasses="rightAligned, centerAligned, leftAligned" rowClasses="standardRow">
					<h:commandLink immediate="true"
						action="#{languageChanger.germanAction}">
						<h:graphicImage value="/german_flag.gif" style="border: 0px" />
					</h:commandLink>
					<h:outputText value=" " />
					<h:commandLink immediate="true"
						action="#{languageChanger.englishAction}">
						<h:graphicImage value="/britain_flag.gif" style="border: 0px" />
					</h:commandLink>
				</h:panelGrid>
			</h:panelGrid>
		</h:panelGrid>
	</h:form>
</f:view>
</body>
<ft:trace />
</html>
```

Ich bekomme ja nicht mal einen Fehler, aber ich müsste doch dann eigentlich so wie im Beispiel die Traces an meine Seiten unten angehängt bekommen, oder?

Gruß Taste


----------



## maki (15. Mai 2008)

Steht was im Log?

Schreib das Tag mal innerhalb des f:view tags statt ausserhalb.


----------



## Taste (15. Mai 2008)

Nun hab ich das Tag vor das EndTag von </f:view> geschrieben, aber leider geht nun nix mehr.

Logfile:



> 15.05.2008 13:19:46 org.apache.catalina.core.StandardContext listenerStart
> SCHWERWIEGEND: Error configuring application listener of class org.apache.myfaces.webapp.StartupServletContextListener
> java.lang.ClassNotFoundException: org.apache.myfaces.webapp.StartupServletContextListener
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1363)
> ...


----------



## Terminator (15. Mai 2008)

> Google und Konsorten sind auch keine JSF Anwendungen  
War auch auf bezogen auf "dynamische Webanwendungen ... nur POST"
Übrigens ist JSF Part of JEE, also n Standard, somit werden meiner Meinung nach fast alle JEE-Anwendungen über kurz oder lang darauf umstellen, auch die grossen Public-Player die JEE nutzen, und die bleiben bei GET Suchen.



> Manche Router unterstützen bis zu 256, manche weniger, deswegen ist GET nicht zuverlässig genug für eine Suche. 
Stimmt.
Behaupte trotzdem mal das alle Suche, oder meinetwegen > 95%, nur GET machen.



> POST rules *g* 
HeHe - finds echt total OK wenn jemand andere Ansicht hat
JSF is halt wirklich POST-lastig, zumindest im Moment.
Würde dem Taste aber trotzdem davon abraten, auch wenn die aktuellen JSF Tutrials/Bücher/Leuts/Compos das sagen.

Bessere JSF GET-Unterstützung/Navi ist nämlich bereits in JSF 2.0 Draft drin:
Allow for bookmarkable JSF pages. More broadly, if HTTP GET can be used, it should be used. 
https://javaserverfaces-spec-public.dev.java.net/proposals/JSF-2_0-draft.html


----------



## maki (15. Mai 2008)

Sieht so aus, als ob deine myfaces jar nicht gefunden wird.

Bekommst du ohne die FacesTrace geschichte dieselben Exceptions?
Wenn ja, kümmere dich erst darum, Exceptions dieser Art darf man nicht einfach ignorieren, das Log lesen ist wichtig.


----------



## Taste (15. Mai 2008)

Ok, das war mein Fehler hab beim deployen mal wieder etwas vergessen, sorry!
Sieht gut aus, jetzt muss ich die interessanten Traces bloß noch verstehen und analysieren...  :### 

Vielen Dank erstmal soweit.
Gruß, Taste


----------



## maki (15. Mai 2008)

> Sieht gut aus, jetzt muss ich die interessanten Traces bloß noch verstehen und analysieren... icon_study.gif


Na dann! 

Achte vor allem auf die messages (Error etc.), auch kannst du alle Objekte unabhängig vom Scope sehen und vor allem siehst du, in welcher Phase abgebrochen wurde.


----------



## Taste (15. Mai 2008)

Ich setze mal das Erledigt-Häkchen noch nicht, aber Du hast mir soweit schonmal sehr geholfen, vielen Dank!


----------



## maki (15. Mai 2008)

> Behaupte trotzdem mal das alle Suche, oder meinetwegen > 95%, nur GET machen.


Stimme ich auch zu, hab ich oft gesehen, gibt nur wenige Ausnahmen, zB. scroogle, da geht es darum  die Privatsphäre zu schützen, schliesslich werden URLs (und damit GET Daten) brav geloggt von vielen ISPs, ist nicht allen Recht das zB. arcor weiss was man so bei Google sucht.



> Bessere JSF GET-Unterstützung/Navi ist nämlich bereits in JSF 2.0 Draft drin:
> Allow for bookmarkable JSF pages. More broadly, if HTTP GET can be used, it should be used.


Ja, verständlich wenn man so etwas wie "permalinks" braucht, kommt man nicht drumrum.
Das geht mit POST eben nicht.


----------



## Terminator (15. Mai 2008)

> Ja, verständlich wenn man so etwas wie "permalinks" braucht, kommt man nicht drumrum.
used wird hier net mit braucht übersetzt, sondern ist gemeint:
Wenn man GET einsetzen kann, dann sollte man auch GET einsetzen


>>Ne Suche sollte immer mit GET realisiert werden
>... Privatsphäre zu schützen ...

ui des stimmt!
das ist echt n Argument gegen ne GET-Suche.
Muss ich mein "immer" streichen, das ist echt dann echt ne falsche Aussage von mir.

Naja was solls muss Taste selber entscheiden was für ne Suche er macht
Find schön beschrieben ists hier, wann man GET und wann POST verwendet soll:
http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist


----------



## Taste (16. Mai 2008)

Also gut, dank des FacesTraces-Tools habe ich herausgefunden, dass die Validierung fehlgeschlagen ist. Konnte das Problem beheben und nun läuft es.

Nochmal vielen Dank!
Gruß, Taste


----------

