Category Archives: JSF

Implementing your own JSF tabview component without Primefaces

At my current company we are finally transitioning away from our well-aged Primefaces 3.0 jsf library and have implemented our own (composite) components for all use cases where we used primefaces thus far. As I learned a few things while implementing the components, I thought I could share it with others as good tutorials for composite components are quite rare.

Our composite component which we will be developing here is a tabview component just like the one you see on this screenshot of primefaces showcase. The tabview needs to render 1-n different tabs which the user can switch through freely with a click to the tab header. It’s a standard widget found in every operating system and many widget frameworks.

We will develop it based on twitter bootstrap markup and you can use it without any additional client javascript, you don’t even need the bootstrap.js as the switching of tabs is entirely done on the server side (we are talkng about JSF here!). The main advantages of it over the primefaces tabview are that you have learned something about jsf and that you can freely change the html markup as you need it. You can use any CSS styling framework you like.

The component should work with every JSF 2.x version.


You can download the complete source code in my tabview github repository. You have to copy the templates and classes to your project manually. Don’t forget to adjust the package name of the class and the component name inside the class. If you have any question or suggestion just leave a comment.

Continue reading Implementing your own JSF tabview component without Primefaces

JSF-updates-angular – How to use angularJS directives to replace JSF components

Writing JSF components is hard and complicated. No one in their right mind writes them. Except when you are a framework developer.

My team is struggling for some time now with Primefaces and its (natural) limitations where one cannot simply change the HTML output to the designers need. So, I spent some days this fall, to try to replace PrimeFaces components with an angular solution, so that PrimeFaces can be completely removed from the application and all components like dialogs or growls are replaced with angular directives.

I didn’t want to use AngularFaces as its trying to put too much magic into the application (for my personal taste). Its very interesting on paper, but when you use it, it seems that every single developer needs to understand exactly both lifecycles of JSF and angularJS and how both frameworks are working. This seems to be a challenge for every decent sized team.

Luckily, the XML parser of JSF leaves HTML tags it does not know of (aka: angularJS directives) alone and just outputs them in the rendered HTML. In a way, that works like the passthrough attributes in JSF 2.2.

As I wanted to use angularJS only as a “widget factory” in a JSF application, I had to solve only a short list of problems:

  • adding the ng-app attribute to the h:body tag is not possible when not using JSF 2.2, Solution: manual bootstrapping like described in angularjs documentation or wrapping your JSF template with a div and the ng-app attribute.
  • inform angularJS about DOM changes after a JSF AJAX request
  • implement a solution so that directives can make JSF AJAX requests, which is not possible out of the box as they can’t have a JSF ID in JSF versions < 2.2

Besides the first, the last two problems were the challenge.

Inform angularJS about DOM changes after a JSF AJAX request

When you load angularJS on page load in a JSF page, its working as expected: its doing its thing and enhances the DOM according to the registered directives. If you don’t use any AJAX requests at all, you are basically done.

The challenge with AJAX requests is, that angularJS needs to be informed about those changes, as they happen outside of an angularJS digest but can contain new DOM nodes with angularJS directives or are destroying/changing existing directives. AngularFaces solved it in a brute-force-like-way: the angularJS app will be completely destroyed and recreated after every JSF AJAX request. But as I only wanted to use directives, that seemed a little harsh for me.

So, after a little experimenting I’m presenting you:

JSF-Updates-Angular (or short: JUA).

Its a (very small) library to update angularJS after every JSF AJAX request:

  • adds 2 event listeners to the JSF JS library for the ajaxComplete and ajaxSuccess events
  • when ajaxComplete event happens, the DOM nodes that are updated by JSF are still unchanged. JUA will iterate through them, searching for nodes with a scope or isolate scope and call the $destroy method on those scopes. Destroying of scopes is done by angularJS itself.
  • when ajaxSuccess event happens, the DOM nodes that are updated by JSF are successfully updated and this library will compile them via angularJS $compile service.

The result is that even DOM nodes which are updated via JSF AJAX requests are enhanced by angularJS directives.

The current state of JUA is not production ready. It was only tested on a few developer machines in a Mojarra JSF 2.1.7 environment (JBoss 7.1.1.). But as I don’t see any JSF dependencies, it should work with any JSF version, provided the JSF AJAX event listener callback interface was not changed.

Trigger JSF AJAX requests inside of directives

When not using JSF 2.2 angularJS directives (aka HTML tags) can’t have JSF IDs and therefore can’t be the source of an JSF AJAX request. But even with JSF 2.2 or when you use a JSF component as a source, you have to build the requests yourself, which is … not so easy.

I made a short-cut here and am using the great OmniFaces library by balusC. With OmniFaces you have a o:commandScript JSF component which registers a global Javascript function to trigger a JSF request. The request can even send a payload with it (PrimeFaces has a similar component). When a angularJS directive needs to send AJAX requests to a managed bean, I’m just using a commandScript call, instead of inventing the wheel again. Works quite nice.

<tabview on-tab-change="makeTabActive">
	<h:panelGroup id="tabs">
		<tab id="detailTab" title="#{msgs.auftrag}" active="#{bean.detailTabActive">
			<h:form id="form">							 
				<o:commandScript name="makeTabActive"
				                 action="#{bean.onTabChangeMethod()}" />
				<h:outputText value="Detail Tab Content" />

(tabView and tab are angularJS element directives)


Use OmniFaces. Really, this library is great!

Re-implement your application in angularJS instead of JSF.

Execute javascript after AJAX request is complete

As pure JSF doesn’t have an easy way (is ANYTHING easy in JSF?) to execute Javascript after a JSF AJAX request, you can use OmniFaces Ajax.oncomplete() for this. Or (if you want) use the onComplete/onCompleteEvent function of JUA which guarentees that your callback listener is called AFTER angularJS was updated:

<h:commandLink value="Do Ajax stuff" action="#{bean.method()">
    <f:ajax update="@form" execute="@this" 
            onevent="jua.onCompleteEvent(" />

Register global function in your directives to call them outside of angularJS digest

My dialog directive – which will be replacing the primefaces dialog component – registers a global javascript function for every dialog name, so that it just can be used like the primefaces dialog. Call anywhere (even in click handlers of JSF components) to show the dialog and dialog.hide() to close it. For developers who don’t know anything about the implementation details, the new dialog behaves just like the PrimeFaces dialog.

$window[scope.dialog] = {
	show: function () {
		$window.jua.ensureExecutionAfterAjaxRequest(function () {
			$scope.apply(function () {
				addOverlay(); = true;
	hide: function () {

(this code is run inside an angularJS directive)

Make use of OmniFaces library components

Use o:messages of OmniFaces to output JSF messages to mimic the PrimeFaces growl component. With o:messages you can control the HTML output of messages and can give an angularJS directive all needed parameters to mimic a growl message.

<messages sticky="true"
	<h:panelGroup id="messages">
		<o:messages var="message" showSummary="true" showDetail="true">
			<message summary="#{message.summary}" detail="#{message.detail}"

(messages and message are angularJS element directives)

Appcache Manifest erstellen und in einer angularJS App integrieren

Wer eine ausgewachsene App entwickelt, die aus rein statischen Dateien (*js, *.css, *.html) besteht und die dynamischen Daten ausschließlich über einen REST-Server nachlädt, sollte sich in jedem Fall mal mit dem HTML5 Appcache beschäftigen. In so einem Fall kann man die (z.B. bei alistapart etwas übertriebenen beschriebenen) Nachteile nämlich ruhig ignorieren.

Der Vorteil für den Nutzer die kompletten statischen Daten immer sofort auf dem Gerät parat zu haben und außer dem REST-Request überhaupt keine HTTP-Requests zum Laden der App zu benötigen, ist speziell für mobile Anwendungen ein ungeheurer Performancegewinn.

Wie ein Appcache-Manifest aufgebaut ist, wird z.B. auf HTML5 Rocks beschrieben.

Nun will man die Datei aber natürlich möglichst automatisch erstellen. Wir haben uns – da wir grunt als Buildtool verwenden – für grunt-contrib-manifest entschieden. Für mich ein weiterer Grund sehr zufrieden mit unserer Entscheidung zu sein, grunt zu verwenden. Es gibt für praktisch alle Anforderungen im Bereich Webentwicklung bzw. Frontend-Entwicklung bereits ein Plugin. [highlight1]”Da gibts ein Plugin für”[/highlight1] statt “Da gibt’s eine App für” sozusagen 🙂

Die Konfiguration ist simpel und selbsterklärend, da muss ich nicht weiter drauf eingehen. Und funktioniert bisher problemlos.

Was etwas mehr nachdenken erfordert hat, war, wie man auf das Event “updateready” reagieren soll, das der Browser erzeugt, wenn er die Dateien im Appcache vollständig aktualisiert hat und die neue Version der App geladen werden muss. Dass eine nicht wegklickbare Info-Box erscheinen sollte, die der Nutzer nur mit einem Klick auf “Neu laden” schließen können sollte, war recht schnell klar. Das eigentliche “Problem” war, das solche DOM-Manipulationen nicht in einen angularJS Controller gehören. Schließlich sollen die auf jeden Fall auch ohne DOM unittest-bar bleiben.

Also war eine Direktive notwendig.

Wir haben es momentan mit dieser Direktive gelöst. Das Popup benutzt jQuery Mobile.

function AppcacheUpdated() {
	var elementScope;

	window.applicationCache.addEventListener('updateready', function() {
		if (window.applicationCache.status === window.applicationCache.UPDATEREADY) {
			window.applicationCache.swapCache(); = true;
			if (!elementScope.$$phase) {

	return {
		template:" <div data-role='popup' class='appcachePopup ui-content' data-theme='e'>" +
			" <p><translate>Neue Version</translate></p><br />" +
			"<a ng-click='reload()' data-role='button'>Neu laden</a> </div>",
		controller: function ($scope){
			$scope.$watch("show", function(value) {
				if (value) {
					$(".appcachePopup").popup("open", {dismissible:false});

			$scope.reload = function() {

			$ = false;
		link: function (scope) {
			elementScope = scope;

angularModule.directive("appcacheUpdated", AppcacheUpdated);

Die Direktive zu verwenden ist simpel, einfach in jede HTML-Seite, auf der sie verwendet werden soll, irgendwo einbauen:


Das ist so ziemlich meine erste Direktive. Mal schauen ob sie auch weiterhin so funktionieren wird, wie sie es momentan tut. Oder ob es dort noch Fallen gibt, über die ich bisher nicht gestolpert bin. Vor allem bin ich mir momentan noch etwas unsicher, ob es günstig ist, sich den “element.$scope” in einer Closure zu merken.

Die Komplexität um angularJS-Direktiven zu schreiben, ist aber in jedem Fall deutlich geringer als JSF-Komponenten zu schreiben. Ich bin immer mehr der Überzeugung, dass JSF für mich keine Zukunft mehr hat, wenn es um Frontend-Entwicklung geht. Der Ansatz auf dem Server das HTML zu rendern und den Client darstellen zu lassen, hat sich in den letzten Jahren einfach überlebt.

Die Entwicklung mit angularJS ist erstens deutlich einfacher und zweitens … macht es einfach Spass. 🙂

Milestone-Releases von JSF 2.2 auf Glassfish 3.1 testen

Markus Eisele hat heute eine Anleitung veröffentlicht, wie man aktuelle Milestone-Releases von Mojarra JSF 2.2 auf Glassfish testen kann, sodass man keinen JEE7 Container wie Glassfish 4 mehr braucht.

Trotz dass Mojarra JSF 2.2 eigentlich kompatibel zu JEE6 Containern ist und somit eigentlich keine Probleme machen sollte, muss man in der aktuellen Version von Glassfish die im Glassfish gebundelte Version von JSF austauschen. Eine Projekt-Abhängigkeit reicht wohl nicht aus.

Markus beschreibt das recht anschaulich und es ist z.B. deutlich einfacher als im JBoss 7.1 ein Myfaces 2.1 einzubauen (was praktisch gar nicht funktioniert).

Somit kann man sich jetzt schon mal mit dem neuen HTML5-Modus in JSF 2.2 beschäftigen.

Download Movie Life (2017)

Life (2017) HD

Director : Daniel Espinosa.
Writer : Rhett Reese, Paul Wernick.
Producer : Bonnie Curtis, David Ellison, Dana Goldberg, Julie Lynn.
Release : March 23, 2017
Country : United States of America.
Production Company : Columbia Pictures, Skydance Productions, Sony Pictures Entertainment (SPE), Nvizage.
Language : 广州话 / 廣州話, English, 日本語.
Runtime : 103 min.
Genre : Horror, Science Fiction, Thriller.

Movie ‘Life’ was released in March 23, 2017 in genre Horror. Daniel Espinosa was directed this movie and starring by Rebecca Ferguson. This movie tell story about The six-member crew of the International Space Station is tasked with studying a sample from Mars that may be the first proof of extra-terrestrial life, which proves more intelligent than ever expected.

Download Movie Life (2017)

Do not miss to Watch movie Life (2017) Online for free with your family. only 2 step you can Watch or download this movie with high quality video. Come and join us! because very much movie can you watch free streaming.

Watch and Download Full Movie Life (2017)

Incoming search term :

Life 2017 HD English Full Episodes Download, Watch Life 2017 Online Putlocker, Life 2017 Episodes Watch Online, movie Life 2017 streaming, Life 2017 English Episodes Free Watch Online, Watch Life 2017 Online Megashare, watch movie Life 2017 now, Life 2017 HD Full Episodes Online, movie Life 2017 download, watch full Life 2017 movie online, Watch Life 2017 Online Free megashare, Life 2017 For Free online, Watch Life 2017 Online Free Viooz, watch full movie Life 2017 online, Life 2017 Online Free Megashare, Life 2017 Full Episodes Online, Life movie trailer, Life 2017 English Full Episodes Download, Life 2017 Full Episodes Watch Online, Life 2017 film trailer, Watch Life 2017 Online Free, Life 2017 Full Episode, watch full Life movie, download film Life, streaming Life film, streaming movie Life 2017, Life 2017 film download, Life 2017 Watch Online, Watch Life 2017 Online Free putlocker, live streaming movie Life 2017 online, watch full film Life 2017, Life 2017 English Full Episodes Watch Online, streaming film Life, download movie Life, download movie Life 2017 now, Life 2017 English Episodes, Life 2017 movie streaming, Life 2017 For Free Online, Life 2017 Episodes Online, watch Life film now, Life 2017 English Full Episodes Free Download, Life 2017 movie download, Watch Life 2017 Online Viooz, film Life 2017, Life 2017 English Episode, Life 2017 English Full Episodes Online Free Download, Watch Life 2017 Online Free Putlocker,

OmniFaces – Das Schweizer Taschenmesser für JSF-Entwickler

Wer sich ein bisschen bei Google nach JSF-Tipps umsieht, wird schnell auf stackoverflow stossen, wo der Autor [highlight2]balusc[/highlight2] schon lange eine Koryphäe ist.

Seit einem halben Jahr stellt er eine eigene JSF-Bibliothek zum Download zur Verfügung, die man durchaus als Schweizer Taschenmesser für JSF-Entwickler bezeichnen könnte: OmniFaces.

OmniFaces ist keine Komponenten-Bibliothek wie PrimeFaces oder RichFaces, sondern ist eine Sammlung von kleinen bis grossen Helferlein, die einem das Leben als JSF-Entwickler deutlich erleichtern.

Der Grund warum ich es in unserem Projekt eingeführt habe, ist der [highlight1]Combined Resource Handler[/highlight1], der JSF endlich ein (fast) vernünftiges Resource-Rendering beibringt.

Wer sich mit Web-Performance auseinandersetzt, wird seit Jahren die immer gleichen Empfehlungen finden: pro Seite genau eine CSS-Datei so früh wie möglich im Header einbinden und genau eine Javascript-Datei möglichst ganz am Ende des HTML-Body einbinden (mit Ausnahme von Ressourcen von einem CDN). Beides ist mit JSF nicht möglich, wenn man Komponenten-Bibliotheken wie PrimeFaces, etc. pp. einsetzt. Der Grund ist, dass JSF 2.0 zwar mittlerweile einen eigenen Resource-Handler hat, aber dieser nur 2 Modi kennt, wie die Ressourcen einer Komponente gerendert werden: im HTML-Kopf in der Reihenfolge wie sie im Code definiert sind oder an der Stelle wo sie im Code definiert sind.

Der Combined Resource Handler von OmniFaces ersetzt den Original JSF Resource Handler und rendert die Resourcen, die normalerweise als Einzel-Ressourcen im HTML-Kopf ausgegeben werden sollen, zusammengefasst als jeweils eine CSS-Datei und eine Javascript-Datei. Beide Dateien bleiben zwar weiterhin im Kopf und werden nicht im Body-Ende gerendert (das würde wegen dem zweiten Modus, dass Ressourcen direkt im Code ausgegeben werden auch gar nicht gehen) aber bei uns hat das schon dazu geführt, dass auf komplexen Seiten statt 4 PrimeFaces-Ressourcen + der Standard-JSF-Javascript-Bibliothek nur noch 1 Javascript-Datei ausgegeben wurde. Genauso bei den Primefaces-CSS-Dateien. search multiple domain names

Wenn man jetzt noch dafür sorgt, dass die eigenen Ressourcen immer am Ende vom HTML-Body stehen, hat man eine (fast) perfekte Ladeperformance von externen Ressourcen erreicht.

Neben dem Combined Resource Handler bietet OmniFaces aber noch eine ganze Menge anderer Funktionen, z.B. ein [highlight1]HTML5-Renderkit[/highlight1] oder diverse Validatoren, um mehrere Felder gemeinsam zu validieren. Eine Übersicht findet man im OmniFaces Showcase

Automatisches Styling von nicht validen Eingabe-Komponenten

Cagatay Civici (Lead Developer von PrimeFaces) hat heute in seinem Blog einen Artikel veröffentlicht, der beschreibt, wie man Input Elementen auf einfachem Weg ein anderes Styling verpasst, wenn die Validierung fehlgeschlagen ist: Styling Invalid Input Fields with JSF.

Die vorgestellte Möglichkeit setzt dabei auf einen PostValidationListener, der am Ende der Validierungsphase aufgerufen wird und alle zu diesem Zeitpunkt invaliden Elementen eine zusätzliche CSS-Klasse gibt, die dann z.B. dem Text einen roten Hintergrund gibt.

Der Nachteil dieser Lösung ist, dass alle Änderungen am Zustand von Komponenten, die nach der Validierungsphase gemacht werden, nicht über diesen Listener laufen und somit auch kein Fehler-Styling bekommen.

So schön die Validierungsphase im JSF ist, ist es aber zumindest in meinen Projekten oft so, dass noch zusätzliche Validierungen in der Application-Phase notwendig sind, die natürlich auch in der GUI irgendwie dargestellt werden müssen. Das spätere Validieren ist z.B. oft notwendig, wenn es Abhängigkeiten zwischen verschiedenen Feldern gibt (z.B. ein Datum ist nur dann gültig, wenn es nach einem anderen Datum liegt) oder wenn ein eingegebener Wert komplexe Logik erfordert, die über EJB/JPA/Hibernate laufen muss und somit eine Transaktion und einen Datenbankzugriff erfordert.

Um dies nicht für jeden Einzelfall neu implementieren zu müssen oder pro Komponente einzeln im Template definieren zu müssen, setze ich einen PhaseListener ein, der in der Render-Phase aktiv wird (also nach der Validierungs- und nach der Aplication-Phase) und allen Komponenten, an denen direkt eine FacesMessage hängt, eine zusätzliche CSS-Klasse gibt. Der Code sieht ungefähr so aus:

public class CssStylePhaseListener implements PhaseListener {
	private static final String INVALID_INPUT_STYLE_CLASS = "error";
    public PhaseId getPhaseId() {  
		return PhaseId.RENDER_RESPONSE;  

	public void beforePhase(PhaseEvent arg0) {
		FacesContext context = FacesContext.getCurrentInstance();  
		UIViewRoot root =  context.getViewRoot();  
		Iterator<String> i = context.getClientIdsWithMessages();

		while (i.hasNext()) {  
			String id =;  
			if (id==null||id.isEmpty()) {
			UIComponent component = root.findComponent(id);  		
			if (component instanceof UIInput) {  
				String style = (String) component.getAttributes().get("styleClass");  
				style = style == null ? "" : " " + style;  
				component.getAttributes().put("styleClass", INVALID_INPUT_STYLE_CLASS + style);  

Ein Eintrag in der faces-config.xml ist auch hier noch notwendig:


Der PhaseListener geht dabei von der Annahme aus, dass direkt an einer Komponente ausschließlich Fehlermeldungen vorliegen und allgemeine Meldungen der Anwendung nicht direkt an einer Komponente hängen. Die automatisch erzeugten JSF-Fehlermeldungen aus der Validierungsphase erfüllen diese Voraussetzung immer. Möchte man eine Fehlermeldung aus der Anwendung heraus direkt an eine Komponente hängen, muss man dessen Client-ID kennen:

public void invalidateComponent(String id, String message) {
	UIComponent component = FacesContext.getCurrentInstance().getViewRoot().findComponent(id);
	UIInput input = (UIInput) component;
	FacesContext.getCurrentInstance().addMessage(input.getClientId(), new FacesMessage(message));

Als Entwickler muss man jetzt nur noch wissen und beachten, dass man Validierungs-Fehler bzw. “richtige” Fehlermeldungen an eine Komponente hängen muss, um dem Benutzer automatisch einen optische Rückmeldung zu geben, dass hier eine Fehleingabe vorliegt.

Ich finde diesen Ansatz kompletter, als den Ansatz von Cagatay, wobei auch mein Ansatz durchaus noch Abhängigkeiten hat, die man als Entwickler kennen muss, so z.B. die ID-Ermittlung der Komponente, die man entweder hard-codieren muss oder die – wenn man sie wie oben beschrieben ermitteln möchte – die verschiedenen NamingContainer auf der Seite berücksichtigen muss, siehe den JavaDoc-Kommentar von “findComponent”.

Verwendung von eindeutigen IDs in JSF2-Naming-Containern

JSF2 bietet mit dem <f:ajax>-Tag wirklich einfach zu verstehende aber trotzdem mächtige Ajax-Funktionen. Die ersten einfachen Versuche gelingen meist innerhalb weniger Minuten und man glaubt dies quasi sofort in eigenen Projekten verwenden zu können.

Mein erster Versuch Ajax in einem JSF2-Projekt für einen Kunden einzusetzen hat mir aber bei der ersten relativ komplexen Seite zumindest für ein bis zwei Stunden eine Menge Kopfzerbrechen bereitet. Dabei ist das Problem reinste Unkenntnis gewesen, weil die wenigsten Tutorials deutlich darauf hinweisen.

Aber was war überhaupt passiert?

Ich hatte eine recht komplexe JSF-Seite erstellt, die über den Facelet-Template-Mechanismus aus mehr als 10 einzelnen XHTML-Seiten gerendert wurde. Eine Datei enthielt einen Primefaces-Dialog mit einer bestimmten ID, der in einer völlig anderen XHTML manipuliert werden sollte. Genauer: nach Klick auf einen Button sollte ein Ajax-Request Daten aus der Datenbank nachladen, die danach in diesem Dialog angezeigt werden sollten.

Der Ajax-Request wurde korrekt abgesetzt, die Daten wurden geladen (über Breakpoints sichtbar) und der Dialog wurde auch geöffnet, allerdings enthielt er keine Daten. Es sah so aus, als wenn er weiter im jungfräulichen Auslieferungszustand wäre. Irgendetwas verhinderte als das neu-rendern des Dialogs.

Nach ein bis zwei Stunden rumrätseln und googeln, sind uns aber die Schuppen von den Augen gefallen und wir machten Bekanntschaft mit dem Konzept der NamingContainer.

Wenn eine JSF-Komponente das NamingContainer-Interface implementiert ist dies eine natürlich Grenze innerhalb derer Komponenten-IDs eindeutig sein müssen und auch sind. Alles was außerhalb des NamingContainers im Komponentenbaum existiert, kann dieselbe ID haben wie eine Komponente innerhalb des NamingContainers. Um trotzdem auf diese äußeren Komponenten zugreifen zu können, muss die ID “fully qualified” vom UIViewRoot aus gesehen angegeben werden. Die einzelnen NamingContainer werden dabei normalerweise durch einen Doppelpunkt getrennt. Die ID muss also in der Form “:ID:ID:ID” angegeben werden. Gestartet wird mit dem Doppelpunkt des UIViewRoot und danach jede ID einer Komponente die einen NamingContainer implementiert.

Die häufigsten Komponenten, die man so benutzt und einen eigenen NamingContainer darstellen sind <h:form>, <h:dataTable> und jede Composite Component. Bei Komponenten aus einer Komponentenbibliothek hängt es von dessen Hersteller ab, ob eine Komponente einen NamingContainer implementiert.

Ein Beispiel:

	<h:form id="form">
		<h:outputText value="Namen eingeben:" />
		<h:inputText value="#{}" />
		<h:commandButton value="Abschicken" action="#{testBean.speichern}">
			<f:ajax render=":form:panel:name" />
	<et:myPanel id="panel">
		<h:outputText id="name" value="Ihr Name: #{}" />

Der Code zeigt ein Eingabefeld und einen Button innerhalb einer Form an und außerhalb der Form wird über eine Composite Component ein Panel gerendert, das den eingegebenen Namen anzeigen soll. Im <f:ajax>-Tag darf man nun nicht nur die ID “name” angeben, sondern die komplette ID inkl. der IDs der Form und der Composite Component, weil beide einen NamingContainer implementieren.

Übrigens lässt sich der Trenner zwischen den einzelnen IDs auch umkonfigurieren. Dazu muss man den Parameter “javax.faces.SEPARATOR_CHAR” in der web.xml entsprechend setzen.

Mehr Informationen über NamingContainer und Komponenten-IDs finden sich bei Illegal Argument Exception

Wirklich unabhängige Composite Components

Im (sehr übersichtlichen) Blog von Michael Kurz habe ich eine sehr interessante Umsetzung einer Composite Component für JSF 2.0 gefunden, die einen komponentenspezifischen Zustand/Information völlig unabhängig von der aufrufenden Seite im JSF Komponentenbaum speichern kann. Die aufrufende Seite muss somit nichts über die Internas der Composite Component wissen und für die Komponente auch keine extra definierten Attribute in einer Managed Bean zur Verfügung stellen. best places to visit . Wenn die Composite Component auf vielen verschiedenen Seiten benutzt wird, führte das meist dazu, dass ein Zustand der Composite Component in vielen verschiedenen Managed Beans gespeichert wurde.

Mit der Lösung von Michael kann eine Composite Component jedoch völlig unabhängig von der aufrufenden Seite Informationen über interne Zustände im JSF Komponentenbaum ablegen, obwohl es weiterhin eine Composite Component bleibt und deutlich schlanker erheblich unkomplizierteer als eine “full fledged” Komponente ist.

Dabei ist zusätzlich zur bekannten XHTML-Datei der Composite Component nur eine weitere Java-Klasse zu erstellen, die noch dazu sehr übersichtlich und unkompliziert ausfällt.

Als ersten Schritt muss man im Kopf der Composite Component auf eine eigene Komponentenklasse verweisen:

<cc:interface componentType="at.jsflive.CollapsiblePanel">
  <cc:attribute name="collapsed"/>
  <cc:actionSource name="toggle"/>
  <cc:facet name="header"/>

Die Implementation dieser Klasse könnte so aussehen:

public class CollapsiblePanel extends UINamingContainer {

  enum PropertyKeys {collapsed}

  public boolean isCollapsed() {
    return (Boolean)getStateHelper().eval(
        PropertyKeys.collapsed, Boolean.FALSE);

  public void setCollapsed(boolean collapsed) {
    getStateHelper().put(PropertyKeys.collapsed, collapsed);

  public void toggle(ActionEvent e) {

Neben der Annotation muss man sich ausschließlich um das Speichern eines Zustands und das Verändern dieses Zustands kümmern. Auf die Methoden kann man innerhalb der Composite Component über das implizite “cc”-Objekt zugreifen, diesmal aber nicht über das attrs-Attribut sondern direkt:

    <h:commandButton id="toggle" actionListener="#{cc.toggle}"
          ? 'jsflive:plus.png' : 'jsflive:minus.png']}"/>

That’s it.

Das ausführliches Beispiel findet ihr im oben verlinkten Blog. Michael Kurz ist übrigens einer der Autoren von Java Server Faces 2.0. Außerdem betreut er das umfangreiche JSF-Tutorial jsfatwork