GET-Parameter: Was spricht gegen outputLinks?

[Ono Sendai]

Hallo, habe eine eher philosophische Frage:

Es gibt jede Menge Artikel in denen Beschrieben wird, wie mit JSF schliesslich doch GET-Parameter benutzt werden können. Von Workarounds bis zur Kritik an JSF ist eigentlich alles vertreten, siehe:

http://www.codegravity.com/blog/jsf-and-get-parameters
http://marcchung.com/2005/01/24/performing-a-jsf-get-2/
http://wiki.apache.org/myfaces/Invok...thStandardUrls
http://www.theserverside.com/news/th...hread_id=38601

Was spricht denn nun eigentlich dagegen, outputLinks zu verwenden, um GET Parameter zu übergeben? Beispiel:
<h: outputLink value="somepage.jsf?name=value" />

Über die EL mit #{param.['name'] oder

HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();

String value = request.getParameter("name");

lassen sich die Parameter ja auch wieder auslesen.

Sicher ist es nicht unbedingt elegant URL's zu hardcoden, aber das sind die vorgestellten Alternativen auch nicht.

[orribl]

Hi Ono Sendai,
ich finde hier muss man unterscheiden.
Bei Formularen macht es natuerlich durchaus Sinn diese nur per POST zu uebergeben, da der Inhalt erst durch den User gefuellt wird.
Bei einfachen Links gebe ich dir recht, da wuerde die Verwendung von GET-Parametern schon Sinn machen (SEO, Boockmarking). Vor allem bei SEO ist die Verwendung von JS ein Problem, da die meisten Suchmaschinen kein Javascript auslesen koennen.
Das Problem bei Bookmarks ist meiner Meinung nach das die Anwendung intern einen bestsimmten Zustand hat (Beziehungen zw. Objekten, aktuelle Werte), der schlecht ueber GET-Parametern wiederhergestellt werden kann.....

[Ono Sendai]

Hi orribl,
danke für deine Überlegung.

den Einsatz von GET-Params sehe ich auch nicht als Alternative zu POST, das würde das Konzept von JSF in Frage stellen. Es geht mir darum, eine einfache Möglichkeit der Wertübergabe beim Klicken auf einen Link zu haben.
Beispiel:
Eine Liste mit Namen von Personen, die angeklickt werden können. Auf der nächsten Seite wird die User-ID der Personen benötigt.

Eine Möglichkeit besteht darin die commandLinks mit ActionListenern zu versehen, dann ist in der aufgerufenen Methode immerhin die Komponenten verfügbar, der kann z.B. im title-Attribut die UserId mitgegeben werden (Das Einschachteln von Komponenten zur Datenhaltung wie die Tomahawk-saveState Komponenten in commandLinks ist IMHO nicht möglich.)

Oder: statt commandLink einen OutputLink mit der ID des Users verwenden.

Ein Nachteil sollte dabei nicht vergessen werden: Mit Klick auf einen outputLink verlässt man den JSF-Lifecycle. Zwar tritt man sofort wider ein, sodass alles was in der Session liegt weiterhin vorhanden ist, dennoch verstösst es gegen den vorgesehenen Datenfluss.

[orribl]

Ich hatte auch das Problem mit Liste und habe es folgendermassen geloest (ich glaube auch das dies der gaengige Weg ist):

BackingBean:

...
private HtmlDataTable inputFieldDataTable;
...
public void btn_editInputField_click(){		
   //set current input field		
   this.currentInputField = (InputField)this.inputFieldDataTable.getRowData();
   ....
   //do sth.		
}

Das ganze natuerlich mit Gettern/Settern...

<rich:dataTable var="inputField" value="#{adminBackingBean.inputFields}" binding="#{adminBackingBean.inputFieldDataTable}">
...
<h:column>							
   <f:facet name="header">
      <h:outputText value="" />
   </f:facet>
   <a4j:commandLink value="bearbeiten" reRender="currentInputFieldDetails,addInputFieldLnk,criteria" action="#{adminBackingBean.btn_editInputField_click}" />					</h:column>
</rich:dataTable>