In der Quelle der Klasse AjaxBehaviorRenderer (line 260) gibt es eine Zeile, die die NamingContainer Id an die Liste der optionalen Parameter mojarra.ab(...) anfügt. Ich habe noch nie über sie kommen, so bin ich neugierig, wann es verwendet wird:Wann fügt Mojarra der Liste der optionalen Parameter einen Benennungscontainer hinzu?
RenderKitUtils.appendProperty(ajaxCommand, "com.sun.faces.namingContainerId", namingContainerId, true);
Linie 260
Während spec issue 790 letzte Woche arbeiten, die u.a. lösen sollte Rendering other form by ajax causes its view state to be lost, how do I add this back?, erklärte mir Neil Griffin, ein Portlet-Typ.
Es scheint, dass Portlets mehrere JSF-Ansichten haben können, die auf dasselbe HTML-Dokument mit jeweils einem eigenen Ansichtszustand rendern. In Portlets gibt es eine spezielle UIViewRoot Instanz, die NamingContainer implementiert. Beim regulären Rendern erhalten alle Formulare, Eingaben und Befehle IDs und Namen, denen die eigene Client-ID der Ansicht vorangestellt ist. Dies funktioniert bei synchronen Postbacks einwandfrei. Das Portlet kann auf diese Weise die genaue Ansicht für die Wiederherstellung identifizieren.
jedoch während asynchroner Postbacks werden die jsf.js eine Reihe von zusätzlichen Ajax-spezifischen Anforderungsparametern erstellen wie javax.faces.source, javax.faces.partial.event usw. Diese Anforderung Parameternamen sind nicht die Ansicht der eigenen Client-ID vorangestellt. Daher kann das Portlet sie keiner bestimmten Ansicht zuordnen. Daher die impl issue 3031.
Es gab ein weiteres Problem von View State Identifiern in Ajax-Antworten, die auf diese Weise nicht richtig Namespaced sind. Daher musste die Portlet-Implementierung den Partial-Response-Writer in der sogenannten "JSF-Bridge" anpassen. Dies wird bei der Implementierung des Spezifikationsproblems 790 berücksichtigt. Statt wie in der aktuellen Implementierung eine "Portlet-Umgebung" zu schnüffeln, wird es eine Prüfung auf UIViewRoot instanceof NamingContainer geben, die flexibler und portletunabhängig ist. Das Mojarra-spezifische com.sun.faces.namingContainerId wird ebenfalls entfernt. Stattdessen wird dieser Wert auf <partial-response id="..."> gerendert, so dass die jsf.js nur von dort extrahieren kann.
Alles in allem nicht wirklich wichtig, wenn Sie nur auf Servlet-basierte Umgebungen abzielen.
Per balusC Kommentar:
Es ist nur interessant für Portlet-basierte Anwendungen (keine Servlet-basierten Apps). Ich kann nicht genau erklären, warum und wofür es verwendet wird (ein Portlet/liveray Typ könnte), aber die Portlet-spezifische Funktion heißt "Namespaced Parameter". Siehe https://web.liferay.com/web/meera.success/blog/-/blogs/liferay-requires-name-spaced-parameters
Es ist nur interessant für Portlet-basierte Anwendungen (nicht Servlet-basierte Anwendungen). Ich kann nicht genau erklären, warum und wofür es verwendet wird (ein Portlet/Liveray-Typ könnte das), aber die Portlet-spezifische Funktion heißt "namespaced parameters". Siehe z.B. https://web.liferay.com/web/meera.success/blog/-/blogs/liferay-requires-name-spaced-parameters Verwandte Probleme: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-861 und https://java.net/jira/browse/JAVASERVERFACES-3031 – BalusC
@BalusC Ich gebe Ihren Kommentar als Antwort. Wenn du es selbst machen willst, antworte einfach und ich akzeptiere deine. Ich mag es nicht, Fragen offen zu haben – Ced