Intersult: JSF Ext

This page (revision-184) was last changed on 21-Apr-2017 08:27 by Dieter Käppel

This page was created on 09-Aug-2012 13:29 by Dieter Käppel

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Pagination: First Previous 2 3 4 5 6 7 8 910all (Total items: 184 )

Version	Date Modified	Size	Author	Changes ...
184	21-Apr-2017 08:27	36 KB	Dieter Käppel	to previous
183	21-Apr-2017 08:27	36 KB	Dieter Käppel	to previous \| to last
182	15-Jan-2016 10:18	36 KB	Dieter Käppel	to previous \| to last
181	15-Jan-2016 10:16	36 KB	Dieter Käppel	to previous \| to last

Pagination: First Previous 2 3 4 5 6 7 8 910all (Total items: 184 )

Page References

Incoming links	Outgoing links
JSF Ext Application Support Faces Filter Intersult Expert Intersult Produkte Intersult Taglib Intersult Unternehmensbewertung Intersult expert Intersult taglib JPA Support JSF Desktop JSF Ext JSF Ext Events JSF Ext Functions JSF Ext Push JSF Ext Scopes JSF Ext Tags JSF Spring Integration JSF2 Jsf desktop Jsf ext Jsf ext events Jsf ext push Jsf ext tags Jsf2 Main Primefaces	JSF Ext Application Application Support Faces Filter Google Application Engine Intersult Plattform Intersult Taglib JPA Support JSF JSF Desktop JSF Ext Events JSF Ext Functions JSF Ext Push JSF Ext Scopes JSF Ext Tags JSF Ext/jsf-ext-cdi.zip JSF Spring Integration JSF2 PDF Renderkit Primefaces

Version management

Difference between version and

At line 4 changed one line

[JSF Ext] wurde weiter vereinfacht, sodass eine hohe Geschwindigkeit der Web-Seiten erreicht werden kann. [JSF Ext] wurde optimiert, sodass höchst mögliche Kompatibilität mit anderen Produkten sichergestellt ist. Sollten Sie Fragen, Bugs oder Feature-Requests haben, so nutzen sie bitte die [Issue List|https://code.google.com/p/jsf-ext/issues/list].

At line 6 changed one line

Einige der Features:

Übersicht der Features:

At line 11 changed one line

* __Events:__ Einfach nutzbare Event-Erzeugung und automatisches Rendering

* __Events:__ Einfach nutzbare Events und automatisches Rendering

* __Push:__ AJAX-Push unabhängig von verwendeten Framework

At line 15 added one line

* __Persistence:__ [JSF Ext] läuft auch ohne Hibernate, diese Funktionalität befindet sich in [JPA Support].

At line 17 added 9 lines

Folgende Inhalte befinden sich auf eigenen Wiki-Seiten:

* [JSF Ext Tags]

* [JSF Ext Scopes]

* [JSF Ext Events]

* [JSF Ext Push]

* [JSF Ext Functions]

* [Faces Filter]

At line 28 changed one line

Die Anwendung befindet sich im [Intersult Maven Repository]:

[JSF Ext] kann von [Central|http://search.maven.org/] bezogen werden:

At line 30 changed one line

In der pom.xml wird angegeben:

In der pom.xml für den Maven-Build wird angegeben:

At line 40 changed one line

<version>2.2-SNAPSHOT</version>

At line 44 removed 8 lines

<id>intersult-repo</id>

<name>Intersult Repository</name>

<url>http://repository.intersult.com/repository</url>

</repository>

...

</repositories>

At line 82 changed 2 lines

!!Redirects

Standardmäßig schicken Command-Tags wie <h:commandButton> das Formular ab und rendern unter umständen eine neue ViewId. Dabei entstehen zwei Probleme:

!!AJAX-Queue

Üblicher Weise werden AJAX-Aufrufe serialisiert. Generell macht dies Sinn, da es sonst zu Problemen mit dem View-State kommt. Aktiviert wird das Parallelisieren von AJAX-Aufrufen durch das Setzen der JavaScript-Variable "jsf.ajaxQueue":

At line 85 removed 5 lines

* Im Browser wird bei einem View-Wechsel die vorherige View-Id angezeigt, anstatt der neuen View-Id.

* Ein Refresh der Seite durch den Browser führt zu Komplikationen, die Submit-Parameter müssen nochmals abgeschickt werden. Die meisten Browser legen dabei ein für den Benutzer wenig verständliches Verhalten an den Tag, Popups öffnen sich mit merkwürdigen Fragen.

Die Lösung besten in einem Redirect nach dem Submit, der häufig Page für Page, Action für Action in das Projekt reingezogen wird. Die Nachteile seitens Wartbarkeit, Konsistenz und Veränderbarkeit liegen auf der Hand. Eine saubere Lösung besteht darin, einen entsprechenden Navigation-Handler zu benutzen:

At line 91 changed one line

<navigation-handler>com.intersult.jsf.util.RedirectNavigationHandler</navigation-handler>

jsf.ajaxQueue = 2;

</script>

At line 94 changed one line

__Hinweis:__ Der Redirect-Navigation-Handler ist per Default deaktiviert, da dies einen erheblichen Eingriff in den Page-Flow und damit das Standard-Verhalten von JSF darstellt. Das Feature kann bei Bedarf durch die oben gezeigte Zeile einfach selbst in die eigene faces-config.xml eingefügt werden.

__Warnung:__ Aus gutem Grund werden die AJAX-Requests üblicher Weise serialisiert. Beim Verwenden paralleler AJAX-Requests besteht die Gefahr, einen veralteten View-State an den Server zu senden. Parallele Requests werden nur korrekt arbeiten, wenn ausgeschlossen wird, dass ein Formular mehrere Abfragen gleichzeitig abschickt.

At line 96 removed 429 lines

!!!Tags

Das [JSF Ext] enthält eine Reine von Tags.

!!Insert Tag

Der Insert Tag kann Components in den Component Tree einfügen, anhand einer EL-Expression. Dies ist unter anderem nützlich, wenn man Composite Components baut. Also Components mit dem Namespace http://java.sun.com/jsf/composite/...

In der Composite Component gibt es nur den Tag <cc:insertChildren>, damit hat man keine detailierte Kontrolle, die Children werden alle an derselben Stelle eingefügt. Möchte man diese zum Beispiel durch ein SPAN-Tag wrappen, braucht man den Insert Tag.

__Lösung:__ Man iteriert durch die Children mittels <c:forEach> und fügt diese an einer beliebigen Stelle mittel <e:insert> ein.

{{{

<?xml version="1.0" encoding="UTF-8"?>

<html xmlns="http://www.w3.org/1999/xhtml"

xmlns:f="http://java.sun.com/jsf/core"

xmlns:h="http://java.sun.com/jsf/html"

xmlns:c="http://java.sun.com/jsp/jstl/core"

xmlns:ui="http://java.sun.com/jsf/facelets"

xmlns:cc="http://java.sun.com/jsf/composite"

xmlns:e="http://java.sun.com/jsf/ext"

xmlns:ext="http://java.sun.com/jsf/composite/ext"

<cc:interface>

<cc:attribute name="align" default="center"/>

</cc:interface>

<cc:implementation>

<c:forEach items="#{cc.children}" var="child">

<h:panelGroup style="padding: 5px 5px 0 0;" rendered="#{child.rendered}">

<e:insert component="#{child}"/>

</h:panelGroup>

</c:forEach>

</div>

</cc:implementation>

</html>

}}}

!!Behavior-Tag

Eine Neuerung bei [JSF2] ist die Einführung von Behaviors, also das Generieren von Java-Script-Snippets aus Java heraus. Ein Behavior kann jeder Komponente hinzugefügt werden, die ClientBehaviorHolder implementiert.

In vielen Fällen hab man bereits Behavior-Components zu einem Tag hinzugefügt. Würde man dennoch das entsprechende Attribut verwenden (z.B. onclick bei commandButton), kann es zu Problemen kommen, wie die Reihenfolge der Snippets oder das "return false;"-Anhängsel.

Lösung bringt der Behavior-Tag von [JSF Ext]. Typisch ist zum Beispiel die Verwendung zusammen mit dem AJAX-Tag:

{{{

<h:commandButton value="X">

<f:ajax/>

<e:unload/>

<e:behavior script="#{rich:component('popup-panel')}.hide(event);"/>

</h:commandButton>

}}}

Die Behavior-Snippets werden in der entsprechenden Reihenfolge produziert:

{{{

jsf.util.chain(this,event,'mojarra.ab(this,event,\'action\',0,0)','RichFaces.$(\'popup:form:popup-panel\').hide(event);');return false

}}}

!!Evaluate Tag

Wenn mit Actions und Java-Script gearbeitet wird, kann eine Ausführung im Erfolgsfall des Form Submit sinnvoll sein. Dies kann durch den Evaluate-Tag erreicht werden, der einen ActionListener darstellt und entsprechendes Script ausführen kann.

{{{

<h:commandButton value="Submit">

<f:ajax/>

<e:evaluate script="alert('Success');"/>

</h:commandButton>

}}}

Zusätzlich ist der Evaluate-Tag ein ClientBahaviorHolder, sodass Behavior-Tags verwendet werden können, um das Script zu erzeugen.

Unterschied zwischen Behavior- und Evaluate-Tag:

||||Behavior||Evaluate

|Zeitpunkt der Ausführung|Direkt durch den Browser-Event|Durch den AJAX-Request an den Browser gesendet

|Bedingungen für die Ausführung|Keine Server-Bedingungen möglich, nur Java-Script if-Statements|Das Script wird nur nach erfolgreichen Submit ausgeführt, also wenn die Validation erfolgreich war

|Anwendungszweck|Steuerung des Browserverhaltens, Ein- und Ausblenden, Fading, dynamische Browserelemente, Client-Behavior|Abwickeln von Server-States, Popups öffnen und Schließen, Submits bestätigen

!!AJAX-Tag

Der AJAX-Tag von [JSF Ext] erlaubt das Abschicken eines anderen Formulars. Der Tag <f:ajax> kann nur das aktuelle Formular abschicken, innerhalb der Action-Source in der er sich befindet.

!Sources

Manchmal ist es sinnvoll andere Sources abzuschicken, dafür stellt [JSF Ext] den Tag <e:ajax> zur Verfügung:

{{{

<h:form id="test-form">

<h:panelGrid columns="3">

<h:outputText value="Name"/>

<h:inputText id="name" value="#{bean.name}" required="true"/>

<h:message for="name"/>

</h:panelGrid>

</h:form>

<h:form id="other-form">

<h:commandButton id="tag-save" value="Tag Button">

<e:ajax source=":test-form" render=":test-form"/>

</h:commandButton>

</h:form>

}}}

Der Tag <e:ajax> ersetzt in diesem Fall den Tag <f:ajax>, er braucht nicht zusätzlich angegeben zu werden.

!Action Source

Der Tag kann auch Actions abschicken, wenn er an einfachen ClientBehaviorHolder gehängt wird, weil er selbst eine ActionSource darstellt:

{{{

<h:panelGrid>

<f:ajax event="dblclick" action="#{bean.action}"/>

</h:panelGrid>

}}}

!Client-Behaviors

Der Tag <e:ajax> ist nicht nur ein ClientBehavior sonder auch selbst wieder ein ClientBehaviorHolder. Er unterstützt die vier AJAX-Events begin, complete, success und error, wobei das Default-Event success ist:

{{{

<h:graphicImage id="edit" value="edit.png">

<e:ajax event="click">

<f:setPropertyActionListener value="#{element}" target="#{editController.element}"/>

<rich:componentControl target=":some-popup" operation="show"/>

</e:ajax>

</h:commandButton>

}}}

!!DIV-Tag

In JSF gibt es eine Reihe von Möglichkeiten, einen DIV- oder SPAN-Tag zu erzeugen, zum Beispiel durch <h:panelGroup>. Dabei handelt es sich jedoch um einfache Komponenten, die keine ClientBehaviorHolder sind, und daher kein <f:ajax>, <e:bahavior> und andere Behaviors unterstützen.

Der Tag <e:div> ist ein vollwertiger ClientBehaviorHolder:

{{{

<e:div id="mouse-active" tabindex="0" onkeypress="alert((event || window.event).keyCode);">

<ext:mouse-focus id="mouse-focus"/>

</e:div>

}}}

Damit wird das Erstellen von einfachen Komponenten mit wenig HTML-Code und flachen Komponenten-Bäumen deutlich vereinfacht.

!!Attribute-Tag

Bei manchen Tags fehlen Attribute, wie zum Beispiel placeholder oder oncontextmenu. JSF-Tags reichen die Attribute nicht durch, daher besteht keine andere Möglichkeit diese Attribute hinzuzufügen. In den meisten Fällen können solche Attribute durch das Attribute-Tag trotzdem hinzugefügt werden:

{{{

<h:inputText id="name" value="#{bean.name}">

<e:attribute name="placeholder" value="Name eingeben..."/>

</h:inputText>

}}}

Des Weiteren unterstützt der Attribut-Tag folgende Attribute:

||Name||Beschreibung

|finalizer|Zeichen für den Abschluss eines Behaviors. Default ist, dieses Zeichen aufgrund einer Reihe von Heuristiken zu erraten. Dazu zählen Behaviors und Attribut-Namen wie z.B. "style" mit den Finalizern ";" und "". Jeder untergeordnete Behavior-, Part- und anderer Tag wird mit diesem Zeichen abgeschlossen.

|delimiter|Zeichen für die Abtrennung untergeordneter Behavior-Tags usw. Im Gegensatz zum Finalizer wird dieses Zeichen nur zwischen den Behaviors eingefügt, nicht jedoch am Ende. Default ist ein einzelnes Whitespace.

__Hinweis:__ Durch dieses Feature können Strings bequem zusammengesetzt werden, die mit Attributen "rendered" versehen sind. Untergeordnete Behaviors, wie das Part-Tag, können die Werte nochmal für einzelne Strings überschreiben.

!Attribute-Behaviors

Der Attribute-Tag ist ein ClientBehaviorHolder, es können also Behaviors darunter gehängt werden wie <e:behavior> oder sogar <e:ajax>. Dadurch ist es möglich, Behaviors für Attribute zu festzulegen, die eigentlich nicht dafür gedacht sind:

{{{

<h:panelGroup>

<e:attribute name="oncontextmenu">

<f:ajax listener="#{bean.render}" render=":some-menu"/>

</e:attribute>

</h:panelGroup>

}}}

!Zusammengesetzte Attribute

Gelegentlich möchte man Attribute zusammen setzen, zum Beispiel um Styles in Composite-Tags zu rendern. Dies kann durch Kombination eines Attribute-Tags und mehreren Behavior-Tags erreicht werden:

{{{

<e:div id="#{cc.id}" styleClass="button-bar">

<e:attribute name="style" renderEmpty="false">

<e:behavior script="text-align: #{cc.attrs.align};" rendered="#{!empty cc.attrs.align}"/>

<e:behavior script="background-color: #{cc.attrs.color};" rendered="#{!empty cc.attrs.color}"/>

</e:attribute>

...

</e:div>

}}}

!Part-Attribute

Zusammengesetzt Attribute können bequem durch <e:part> erzeugt werden:

{{{

<h:commandButton>

<e:attribute name="value">

<e:part value="This"/>

<e:part value="is"/>

<e:part value="a"/>

<e:part value="composed"/>

<e:part value="value"/>

</e:attribute>

</h:commandButton>

}}}

__Hinweis:__ Der Part-Tag kann hilfreich sein, wenn bedingte styleClass-Attribute auftreten. Entsprechende Teile können mit dem rendered-Attribut gesteuert werden, anstatt unübersichtliche EL-Expressions zu konstruieren.

!Style-Attribute

Da Style-Attribute besonders häufig auftreten und zusammengesetzt werden, gibt es dafür einen eigenen Tag:

{{{

<e:div>

<e:attribute name="style">

<e:style name="text-align" value="#{valueEdit.permission.field.type.align}"/>

<e:style name="width" value="100%"/>

<e:style name="margin-left" value="10px"/>

</e:attribute>

</e:div>

}}}

!!Reference-Tag

__Achtung:__ Der Reference-Tag wird nicht mehr unterstützt.

__Begründung:__ Der Reference-Tag wird seit längerem durch Scopes ersetzt. Diese sind wesentlich besser in JSF integriert, brauchen weniger Ressourcen und sind flexibler in der Anwendung.

!!New-Tag

Der Tag <e:new> kann an jeder Stelle verwendet werden, an der auch <f:param> verwendet wird:

{{{

<e:load scopeId="test-scope">

<e:new name="bean" type="com.intersult.test.Bean"/>

</e:load>

}}}

Es ist auch möglich, Properties der neuen Bean Werte zuzuweisen:

{{{

<e:new name="bean" type="com.intersult.test.Bean">

<f:param name="param1" value="#{some-expression}/>

</e:new>

}}}

__Hinweis:__ Es ist zu erwähnen, dass das Instantiieren von Beans durch den New-Tag möglicher Weise nicht die beste Praxis ist. Die erste Wahl beim Erzeugen von Beans sollte das Verwenden von Scope- und Factory-Annotations sein, entweder über JSF mit @ManagedBean oder über Spring mit @Component. An zweiter Wahl steht das Erzeugen im Java-Code, zum Beispiel mit Lazy-Initialization Pattern "if (bean == null) bean = new Bean();". <e:new> macht vor allem da Sinn, wo eine neue leere Bean erzeugt werden soll (z.B. Create Popup) und wo mehrere Parameter durch eine Bean übergeben werden sollen.

!!Set-Tag

Eine gängige Praxis ist das Setzen von Java-Properties mittels <f:setPropertyActionListener>. Bei Composite Components können ebenfalls als ActionSource agieren:

{{{

<?xml version="1.0" encoding="UTF-8"?>

<html xmlns="http://www.w3.org/1999/xhtml"

xmlns:ui="http://java.sun.com/jsf/facelets"

xmlns:h="http://java.sun.com/jsf/html"

xmlns:f="http://java.sun.com/jsf/core"

xmlns:e="http://java.sun.com/jsf/ext"

xmlns:c="http://java.sun.com/jsp/jstl/core"

xmlns:cc="http://java.sun.com/jsf/composite"

<cc:interface>

<cc:attribute name="label"/>

<cc:attribute name="action" targets="link" method-signature="void action()"/>

<cc:actionSource name="action" targets="link" default="true"/>

</cc:interface>

<cc:implementation>

<h:commandLink id="link"

<h:outputText value="#{cc.attrs.label}"/>

</h:commandLink>

</cc:implementation>

</html>

}}}

Dieser Tag kann wie folgt verwendet werden:

{{{

<app:myLink label="Some Link">

<e:set value="Some Value" target="#{bean.value}"/>

</app:myLink>

}}}

Beim Verwenden von <f:setPropertyActionListener> müsste man explizit mit einem Attribut for="action" die Action spezifizieren. Der Tag <e:set> macht dies automatisch, bei häufigem Verwenden sieht der kurze Name einfach ausdrucksvoller und aufgeräumter aus.

!!Label

[JSF Ext] liefert einen Tag <e:outputLabel> mit, der auf Required-Attribute mit einem unterschiedlichen Style reagiert. Zusätzlich berücksichtigt werden die Annotations @NotNull und @NotEmpty auf den durch EL-Expressions gebundenen Bean-Klassen.

Die Verwendung ist identisch mit <h:outputLabel>:

{{{

<e:outputLabel for="username:username" value="#{messages['user.username']}"/>

<ext:input id="username">

<h:inputText id="username" value="#{userRegister.user.username}"/>

</ext:input>

}}}

Dabei kommen die beiden CSS-Style-Klassen label-required und label-not-required zum Einsatz, die mit "font-weight: bold;" und "color: #a0a0a0;" vorbelegt sind. Diese können durch ein Benutzer-Stylesheet überschrieben werden.

Der <e:outputLabel> unterstützt das Attribut disabled, mit dem der Label als optional angezeigt werden kann, unabhängig von der tatsächlichen Required-Eigenschaft. Dies ist nützlich, wenn die zugehörige Input-Component ebenfalls Disabled wird.

!!Busy Pointer

Die Integration von AJAX in die Anwendung findet vom Browser zunächst transparent statt. Der Benutzer hat keinen Hinweis, dass gerade eine Server-Aktion erfolgt. Der Vorteil ist, dass der Benutzer mit dem Browser normal weiter arbeiten kann. In vielen Fällen ist dies auch möglich, da Operationen unabhängig voneinander ausgeführt werden können. Der Nachteil ist, dass der Benutzer keinen Hinweis erhält, dass die beabsichtigte Operation angelaufen ist.

In den Anwendungen werden daher unterschiedlichste Elemente in die Seite eingebaut, von rotierenden, blinkenden durch durchlaufenden Bildern bis zu Seiten abdunkelnden und sperrenden Elementen. Das übliche Verfahren von Anwendungen die Verarbeitung einer Operation zu zeigen, ist den Mauszeiger als Busy Pointer darzustellen.

Also wieso nicht auch im Browser bei JSF-Anwendungen den Busy Pointer aktivieren. Der Benutzer wird nicht abgelenkt durch zappelnde Bilder, es wird nichts gesperrt, da die Seite ja weiterhin funktional ist:

{{{

<ext:busyPointer/>

}}}

Optional kann das Attribut cursor angeben werde, das per default auf "wait" gesetzt ist.

!!Mouse Visibility

Auf Seiten die sehr viele Elemente enthalten kann es die Übersicht verbessern, wenn Elemente erst bei Mouse-Over angezeigt werden. Durch reine CSS-Styles ist das meist nicht zu realisieren, weil das Mouse-Over-Element ein Parent-Element des anzuzeigenden Elements ist. Lösungen mit A-Tags, die man häufig findet, führen zu Nebenwirkungen wie Anchor-Links und ungewollten GET-Requests.

Eine Lösung ist der Tag <ext:mouse-visibility>:

{{{

<e:div>

<h:outputText id="project" value="#{processDetails.process.project.name}"/>

<ext:mouse-visibility for=":process-form:image"/>

<h:graphicImage id="image" name="edit.gif" library="images/bitcons">

<e:ajax event="click">

<e:load scopeId=":projectEdit">

<f:param name="project" value="#{project}"/>

</e:load>

</e:ajax>

</h:graphicImage>

</e:div>

}}}

Darüber hinaus gibt es noch die Tags <ext:mouse-display> mit welcher der Display-Style eines Elements gesteuert werden kann. Besonders schick ist auch der <ext:mouse-fade>, mit der das Element ein- und ausgefadet wird.

!!Move-Listener

Auf modernen Web-Seiten wird mehr und mehr mit Popups und Elementen gearbeitet, die mit der Maus verschoben werden können. Der Move-Listener ist ein Event-Generator, mit dem solche Eingriffe verarbeitet werden können:

{{{

<e:moveListener listener="#{dialog.moveListener}"/>

}}}

[JSF Ext] enthält eine Custom-Scoped Bean "dialog", in der das Ergebnis gespeichert werden kann. Im obigen Beispiel geschieht dies durch listener="#{dialog.moveListener}". Ein entsprechendes Popup kann dann durch position="#{dialog.position}" wieder positioniert werden.

Um einem Primefaces-Dialog einen Listener hinzuzufügen, verwendet man:

{{{

<e:moveListener listener="#{dialog.moveListener}"

targetNode="document.getElementById('#{cc.clientId}:dialog').childNodes[0]"

height="element.childNodes[1].offsetHeight - 16"

width="element.childNodes[1].offsetWidth"/>

}}}

!!Init-Tag

In einigen Situationen ist es hilfreich, wenn eine Bean an einer bestimmten Stelle im Component-Tree initialisiert werden kann. So kann beispielsweise ein HTTP-GET-Parameter verarbeitet werden oder ein Scope initialisiert. Dazu gibt es den Tag <e:init>:

{{{

<e:init action="#{testBean.init}"/>

}}}

__Hinweis:__ Die Action-Methode kann mehrfach aufgerufen werden, wenn Redirects durchgeführt werden.

Der Tag kann innerhalb eines Scopes verwendet werden, um den Scope zu initialisieren, falls kein Laden mit <e:load> erfolgt ist.

{{{

<e:scope id="test" load="true">

<e:init action="#{testBean.init}"/>

...

</e:scope>

}}}

{{{

public class TestBean {

@ScopeValue

private String test;

public void init() {

ExternalContext externalContext = FacesContext.getCurrentInstance().getExternalContext();

String test = externalContext.getRequestParameterMap().get("test");

if (test != null)

this.test = test;

}

...

}

}}}

__Hinweis:__ Der Load-Tag ist dabei weiterhin möglich.

Der Init-Tag ist eine ActionSource und kann damit auch ActionListener als Unterobjekte haben:

{{{

<e:init>

<e:set value="#{value}" target="#{target}"/>

</e:init>

}}}

!!Otherwise-Tag

Da ist mit dem <c:choose>, <c:when> und <c:otherwise> Konstrukt in JSF Probleme gibt, enthält [JSF Ext] eine neue Implementierung von Otherweise als Component <e:otherwise>. Diese Component ist einfacher in der Nutzung:

* Als Basis der Choose-Liste kann eine beliebige Component verwendet werden

* Child-Components werden mit rendered-Attributen versehen

* Der Otherwise-Tag wird hinzugefügt und rendered dann, wenn keine der anderen Components gerendert wurde

Das Ganze sieht dann so aus:

{{{

<e:div>

<h:selectBooleanCheckbox id="boolean" value="#{bean.value}" rendered="#{bean.type == 'boolean'}"/>

...

<e:otherwise>

<h:inputText id="text" value="#{bean.value}"/>

</e:otherwise>

</e:div>

}}}

!!Render-Tag

Der Tag <e:render> ist ein nützlicher Tag für dynamische Web-Seiten, in denen Teile automatisch refreshed werden. Bisher gibt man im Ajax-Tag eine Liste von Elementen an, die neu gerendered werden sollen.

Die alte Implementierung über Render-Attribute führt zu folgenden Verbesserungswünschen:

* __Dynamik:__ Zum Zeitpunkt des Ausführens der Render-Anweisung ist unklar, welche Bereiche überhaupt neu gerendered werden brauchen. Die Zielbereiche können über das Render-Attribut, Scopes und andere Mechanismen dynamisch ein- und ausgeblendet werden. Man möchte die Veränderung einer Struktur melden können, unabhängig von den zur Laufzeit tatsächlich abhängigen Elementen.

* __Weiterentwicklung:__ Nach Schreiben der Render-Anweisung wird die Anwendung weiterentwickelt. Zielbereiche zum Rendern können hinzukommen oder wegfallen, dies führt zu permanenter Pflege einer wachsenden Zahl von Render-Attributen in der Anwendung. Gewünscht ist, dass fertiger Code nicht permanent wieder angefasst werden braucht.

* __Modularisierung:__ Bei Modulen, die durch JAR-Dateien ins Projekt kommen, kann auf die XHTML-Seiten kein Einfluss genommen werden. Dort soll ebenfalls ein Rendering möglich sein.

Die Lösung sind Events und der Render-Tag. Typischer Weise werden Events durch den Code ausgelöst, wie etwa beim Login:

{{{

Event.instance().raise(EVENT_LOGIN, authentication.getPrincipal());

}}}

Dadurch werden Bereiche neu gerendered:

{{{

<h:form id="process-form" enctype="multipart/form-data" styleClass="ui-widget" style="margin-left: 10px;">

<e:render event="intersult.subflow.Authenticator.login"/>

<e:render event="intersult.subflow.Process.change"/>

<e:render event="intersult.subflow.Process.select"/>

<e:div rendered="#{!empty processDetails.process}">

...

</e:div>

</form>

}}}

__Hinweis:__ Es können nur Bereiche neu gerendered werden, die bereits gerendered wurden. Dadurch können Render-Tags dadurch problemlos in Scopes und anderen dynamischen Berechen verwendet werden. Es ist völlig verträglich, wenn ein Abschnitt mit einem Render-Tag selbst nicht gerendered wurde, dieser wird dann einfach ignoriert.

__Tipp:__ Soll ein Bereich durch ein Render-Tag ein- und ausgeblendet werden, platziert man den Render-Tag in die übergeordnete Component. So wird die Region auf jeden Fall gerendered, unabhängig vom Render-Zustand (Render-Attribut, <c:if> etc.) der innen liegenden Sektion.

At line 567 changed one line

JSF-Behaviors bestehen aus einer Klasse die von Behavior oder ClientBehavior abgeleitet sind. Im Wesentlichen ist eine Methode getScript enthalten, mit der ein Fragmet des entsprechenden event-Attribut des entsprechenden HTML-Tags gerendert wird, also zum Beispiel onclick="...". Bei komplexeren Behaviors braucht man zusätzlichen HTML-Code, der kann an dieser Stelle nicht geschrieben werden. Ursache ist dass der HTML-Writer sich gerade innerhalb des geöffneten Tags befindet und startElement ungültiges HTML erzeugen würde.

JSF-Behaviors bestehen aus einer Klasse die von Behavior oder ClientBehavior abgeleitet sind. Im Wesentlichen ist eine Methode getScript enthalten, mit der ein Fragment des entsprechenden event-Attribut des entsprechenden HTML-Tags gerendert wird, also zum Beispiel onclick="...". Bei komplexeren Behaviors braucht man zusätzlichen HTML-Code, der kann an dieser Stelle nicht geschrieben werden. Ursache ist dass der HTML-Writer sich gerade innerhalb des geöffneten Tags befindet und startElement ungültiges HTML erzeugen würde.

At line 579 changed 2 lines

!!!Events

Events sind eine Erweiterung des Action- und Update-Systems von JSF. Events können von der Java- und XHTML-Seite erzeugt und konsumiert werden.

!!Components referenzieren

In JSF gibt es drei Arten von Referenz-Ausdrücken in render und execute Ausdrücken, relative, absolute und meta:

At line 582 changed 10 lines

||Name||Java||Parameter||Beschreibung

|javax.faces.post_construct|Event.EVENT_POST_CONSTRUCT|Object managedBean|Der Event wird nach dem Erzeugen einer managed Bean durch das JSF-System erzeugt.

|javax.faces.pre_destroy|Event.EVENT_PRE_DESTROY|Der Event wird vor dem Entfernen einer managed Bean erzeugt.

|javax.faces.event|Event.EVENT_EVENT|String event, Object... arguments|Dieser Meta-Event wird bei jedem Event erzeugt, sodass allgemeine Event-Handler geschrieben werden können. Dies ist mit Vorsicht zu verwenden.

|javax.faces.messages|MessageHandler.EVENT|-|Der Event wird erzeugt, wenn Faces Messages vorliegen.

|login.before|Login.EVENT_LOGIN_BEFORE|-|Bevor ein Benutzer eingeloggt wird.

|login.success|Login.EVENT_LOGIN_SUCCESS|-|Nachdem ein Benutzer erfolgreich eingeloggt wurde. Der Benutzer ist über Login.instance().getUser() abrufbar.

|login.fail|Login.EVENT_LOGIN_FAIL|-|Nachdem ein Login fehlgeschlagen ist.

|login.after|Login.EVENT_LOGIN_AFTER|-|Nach dem Login-Prozess, unabhängig ob er erfolgreich oder fehlgeschlagen ist.

|login.logout|Login.EVENT_LOGOUT|-|Nach dem Logout.

* __Absolute:__ Beispielsweise :form:panel:input-text

* __Relative:__ panel:input-Text

* __Meta:__ @this, @component, @form, @all

At line 593 changed 2 lines

!!Hintergrund

In [JSF] werden oft Render-Attribute direkt in AJAX- und anderen Anweisungen angegeben. Da diese lose gekoppelt sind, wird im günstigen Fall eine Fehlermeldung entstehen, dass die entsprechende Id nicht mehr im Component Tree vorhanden ist. Der nachträgliche Einbau zusätzlich zu rendernder Components ist nicht vorgesehen, diese müssen explizit am Render-Attribut aller betreffenden Anweisungen hinzugefügt und gepflegt werden.

Meist arbeitet man soweit es geht mit relativen Ausdrucken und wechselt notfalls zu absoluten. Um die allgemeine Verwendbarkeit von absoluten Ausdrücken in Composite Components zu gewährleisten, beginnt man diese etwa mit :#{cc.clientId}:input-Text. Das funktioniert leider nicht immer, insbesondere wenn Tabellen, For-Tags oder andere dynamische Elemente darüber liegen.

At line 596 changed one line

Aus diesem Grund führt [JSF Ext] die (Render-)Events ein. Events können zwar aus der View durch den Tag <e:raise> erzeugt werden, sinnvoll ist meist jedoch die Erzeugung durch die raise-Methode auf der Java-Seite. Dadurch bleibt die lose Kopplung von View und Controller erhalten. Die können Controller können Ereignisse auslösen, auf die sich Teile der View registrieren um neu gerendert zu werden.

Dazu führt [JSF Ext] die Syntax ".." ein, die man bereits von relativen Pfadangaben im Dateisystem kennt. Damit ist es nun möglich innerhalb einer Composite Component einen oder einige Components nach oben zu gehen und von dort ab etwas zu selektieren. Also die Kombination von relativen Angaben und Erreichbarkeit der Components:

At line 598 removed 5 lines

!!Java

Ein Event wird erzeugt, indem die Instanz von Event geholt wird. Dies kann durch @ManagedProperty("#{event}") geschehen oder durch die statische Methode Event.instance(). Dabei ist zu beachten, dass keine Session scoped Bean in einen Application Context injected wird.

Das Session basierte Event-Objekt enthält die Methode raise(String event, Object... arguments), also im einfachsten Fall:

At line 604 changed one line

Event.instance().raise("com.intersult.some-event");

<e:ajax render="..:#{cc.id}:panel"/>

At line 607 changed one line

Die Events werden in der Regel durch eine Annotation konsumiert:

__Hinweis:__ Jede Angabe von ".." geht eine Naming-Container nach oben. Components die kein Naming Container sind, werden dabei übersprungen, ebenso wie beim ursprünglichen Absteigen im Component Tree mit x:y:z.

At line 609 removed 474 lines

{{{

@Listener("com.intersult.some-event")

public void someEvent() {

}

}}}

Es ist zu beachten, dass Events nur empfangen werden wenn eine Bean tatsächlich instantiiert ist.

!!FacesMessages

Events können auch im XHTML verarbeitet werden, indem bestimmte Bereiche neu gerendert werden.

!FacesMessages

Zum Beispiel der vorgefertigte Event javax.faces.messages, der bei vorhandenen Faces-Messages ausgelöst wird:

{{{

<e:render event="javax.faces.messages" target="messages"/>

<h:messages id="messages" globalOnly="true"/>

}}}

__Ergebnis:__ Die Faces-Messages werden gerendered, ohne dass bei jedem AJAX-Tag ein gesondertes Rendered-Attribut angegeben werden muss.

__Hinweis:__ Hier wird der Render-Tag nicht im Messages-Tag verschachtelt, weil der Messages-Tag das Rendern von Child-Tags ausdrücklich verhindert.

!Beispiel Input-Wrapper

__Situation:__ In einer Anwendung kommen zumeist verschiedene Eingabeelemente wie <h:inputText>, <h:selectOneMenu>, <h:inputSecret>, <h:selectBooleanCheckbox> sowie selbst gebaute Tags zur Verwendung. Für die Applikation besteht gewöhnlich ein einheitliches Layout mit AJAX- oder Client-Side Validierung, FacesMessages und weiteren Elementen.

__Lösung bisher:__ In vielen Projekten wird für jedes Input-Element ein Composite-Tag gebaut, in dem der Code für AJAX, Validierung, Messages und so weiter wiederholt wird.

Mit [JSF Ext] kann ein generischer Wrapper für Input-Elements gebaut werden:

{{{

<?xml version="1.0" encoding="UTF-8"?>

<html xmlns="http://www.w3.org/1999/xhtml"

xmlns:f="http://java.sun.com/jsf/core"

xmlns:h="http://java.sun.com/jsf/html"

xmlns:c="http://java.sun.com/jsp/jstl/core"

xmlns:ui="http://java.sun.com/jsf/facelets"

xmlns:cc="http://java.sun.com/jsf/composite"

xmlns:e="http://java.sun.com/jsf/ext"

xmlns:ext="http://java.sun.com/jsf/composite/ext"

xmlns:p="http://primefaces.org/ui"

<cc:interface>

</cc:interface>

<cc:implementation>

<e:insert component="#{cc.children[0]}">

<f:ajax event="change"/>

</e:insert>

<h:message id="#{cc.children[0].id}-message" for=":#{cc.children[0].clientId}">

<e:render for=":#{cc.children[0].clientId}"/>

</h:message>

</cc:implementation>

</html>

}}}

Die Anwendung dieses Composite-Tags ist dann wie folgt:

{{{

<h:form id="form">

<app:input id="text">

<h:inputText id="text" value="#{test.text}"/>

</app:input>

<h:commandButton value="Submit" action="#{bean.action}">

<f:ajax/>

</h:commandButton>

}}}

__Erklärung:__ Die Composite-Component wrappt das Input-Element, welches innerhalb des Composite Tags durch <e:insert> eingefügt wird. Der Zugriff erfolgt dabei durch die EL-Expression cc.children[[0].

!!Component FacesMessages

[JSF Ext] generiert auch Events für Component FacesMessages, die entstehen beim Konvertieren, Validieren oder manuell in Java-Code. Oft wird unnötiger Weise das komplette Form neu gerendert, um die Component FacesMessages anzuzeigen. Mit [JSF Ext] können gezielt einzelne Messages gerendert werden, wenn diese auftreten. Um eine Komponenten durch eine Faces-Message rendern zu lassen, kann das for-Attribut verwendet werden:

{{{

<e:render for=":form:some-text"/>

}}}

Der Event tritt in folgenden Fällen auf:

* Nur wenn die Component vom AJAX-Execute betroffen ist

* Wenn eine FacesMessage für die Component zum ersten Mal vorhanden ist

* Wenn eine FacesMessage für die Component zum zweiten oder öfteren Mal vorhanden ist

* Wenn keine FacesMessage für die Component verschwunden ist

__Hinweis:__ Das For-Attribut löst nur die Client-Id auf, das heißt es können relative Id's benutzt werden oder die @-Aliase. Letztlich entspricht es einem Event mit der vollen ClientId der Component, also <e:render for="text"/> hat denselben Effekt wie <e:render event=":form:panel:text"/>. Das Verwender des For-Attributs erleichtert allerdings den Bau der Komponenten und vermeidet Fehler, indem die Id validiert wird.

!!Raise-Component

Events können hervorragend dazu benutzt werden, um AJAX-Submits und Rerendering voneinander zu trennen. Events werden dabei durch Components erzeugt und von anderen Components konsumiert. So braucht die erzeugende Component zur Erstellungszeit nicht wissen, welche Components rerendered werden:

{{{

<h:commandButton value="Submit">

<f:ajax execute="@form"/>

<e:raise name="com.intersult.test"/>

</h:commandButton>

}}}

Hier ist zu beachten, dass ein AJAX-Tag zusätzlich verwendet wird. Bei vollen GET- oder POST-Requests machen Events keinen Sinn, da hier sowieso die komplette Seite gerendered werden würde.

Das Konsumieren kann wieder auf ähnliche Weise erfolgen:

{{{

<h:outputText id="output" value="#{bean.text}">

<e:render event="com.intersult.test"/>

</h:outputText>

}}}

Es ist zu beachten, dass bei der Update-Component (hier outputText) eine Id angegeben wird, damit der AJAX-Handler das Rerendering zuordnen kann. Dies tritt beim Verwenden des render-Attributs nicht auf, da durch die Angabe einer Id ja eine vergeben wurde.

!!Hinweise

Events sind momentan Session-basiert, das heißt es existieren keine Application übergreifenden Events.

!!!Scopes

Jeder der mit Web-Seiten zu tun hat, insbesonder mit JSF, hat schon mit viel Enthusiasmus viele Features, Popups und Steuerelemente in eine Seite eingebaut. Hinterher war die Seite dann so langsam, dass sie eigentlich nicht mehr benutzbar war, hohe CPU-Last und Speicherverbrauch auf dem Server verursacht hat.

Scopes nehmen sich genau diesem Thema an, Komponenten können in einen Scope verpackt werden, und zwar komplett. Das heißt XHTML-Dateien, JSF-Komponentenbäume und Managed-Beans. Teile einer Seite können durch AJAX bei Bedarf geladen und auch wieder entladen werden. Damit kombinieren Sie komplexe Funktionalität auf einer Seite mit Leichtgewichtigkeit und Schnelligkeit. Zusätzlicher Vorteil: Komponenten die in Scopes liegen, können auf jeder Seite wieder verwendet werden - sogar mehrfach gleichzeitig.

Im Detail sind Scopes abgetrennte Bereiche auf einer JSF-Seite, mit eigenen Variablen und einer XHTML-View. Beim Laden können Parameter durch <f:param> übergeben werden, diese sind dann über EL-Expressions durch #{scope.<...>} und Bean-Injections @ScopeValue zugreifbar.

Grundsätzlich gibt es zwei verschiedene Arten von Scopes: Scopes mit dem Tag <e:scope> (gebundene Scopes) und Scopes ohne diesen Tag (freie Scopes).

||||Gebundener Scope||Freier Scope

|View-Id|Die View ist direkt über den Tag zugeordnet.|Die View wird erst beim erzeugen durch den Load-Tag festgelegt.

|Anzahl|Der Scope ist durch den Tag festgelegt und kann nur geladen (load) und entladen (unload) werden.|Der Scope kann beliebig oft durch einen Load-Tag instantiiert werden. Dadurch sind unabhängige und sich wiederholende Popups realisierbar.

|Scope-Id|Der Load-Tag referenziert den Scope direkt über seine Scope-Id.|Dem Scope kann über den Load-Tag eine Id zugewiesen werden, wiederholte Load-Actions greifen damit auf denselben Scope zu. Wird keine Scope-Id zugewiesen, erzeugt jeder Load-Tag einen neuen Scope.

|Unload|Der Scope kann sowohl von innen durch einen Unload-Tag entladen werden, als auch von außen durch Angabe der Scope-Id.|Der Scope kann nur entladen werden, wenn eine Scope-Id angegeben wurde. Ohne Scope-Id kann der Scope von innen, durch einen Unload-Tag ohne Scope-Id entladen werden.

|Position|Die View wird dort eingefügt, wo der Tag platziert wurde. Damit ist genau steuerbar, an welcher Stelle der HTML-Code gerendert wird.|Die View wird im HTML-Body eingefügt. Es ist nicht weiter steuerbar, an welcher Stelle die View gerendert wird.

|Anwendungszweck|Hauptsächlich Bildschirmelemente die an verschiedenen Positionen einer Applikation eingefügt werden sollen und dahinter liegende Scoped-Beans besitzen.|Vor allem Popups, die Details einer Information anzeigen und/oder mehrfach abgebildet werden sollen.

!!Freien Scope erzeugen

{{{

<h:commandButton value="Test">

<f:ajax/>

<e:load viewId="/dialog/test.xhtml"/>

</h:commandButton>

}}}

__Erklärung:__ Der Command-Button läd einen neuen Scope mit der View /dialog/test.xhtml. Die View wird angezeigt und hat Zugriff auf Custom-Scoped Variablen.

!!Direkter Scope

Ein direkter Scope beginnt mit einem Scope-Tag:

{{{

<e:scope id="scope-id">

<h:outputText value="#{scope.id}"/>

</e:scope>

}}}

!!Scope mit Facelet-View

Die Scopes sind eines der mächtigsten Features im [JSF Ext]. Ein Scope wird zunächst im XHTML definiert:

{{{

<e:scope id="popup" viewId="/popup.xhtml"/>

}}}

Diese Definition fügt einen Scope in den Component-Tree ein. Der Scope ist ein UINamingContainer, die Id wird also zu jeder enthaltenen Komponente als Prefix vorangestellt. Zum Beispiel erzeugt <h:inputText id="name" value="#{bean.name}"/> die Ausgabe von <input name="popup:name">.

Dieser Scope verweist auf die viewId "/popup.xhtml", damit ist ein Facelet innerhalb der Web-Applikation gemeint, vergleichbar zu <ui:include>. Das Facelet wird allerdings (zunächst) nicht geladen, im Komponentenbaum befindet sich ausschließlich die Scope Component.

!!Scope laden

Zum passenden Zeitpunkt soll der Scope natürlich geladen werden, das heißt das mit viewId verwiesene Facelet wird tatsächlich in den Component-Tree eingefügt und per AJAX an den Client übertragen. Dies geschieht mit:

{{{

<e:load viewId="/dialog/test.xhtml"/>

}}}

Das Load-Tag ist ein ActionListener, wird also unterhalb einer ActionSource eingefügt, wie zum Beispiel das <f:actionListener> oder <f:setPropertyActionListener>. Im Zusammenspiel mit AJAX kann nun der Scope dynamisch geladen werden:

{{{

<h:commandButton id="load-popup" value="Load Popup">

<f:ajax/>

<e:load viewId="/dialog/test.xhtml"/>

</h:commandButton>

}}}

Beim Laden des Scopes können zusätzlich Parameter übergeben werden:

{{{

<h:commandButton id="load-popup" value="Load Popup">

<f:ajax render=":popup:form"/>

<e:load viewId="/dialog/test.xhtml">

<f:param name="someParam" value="someValue"/>

<f:param name="someExpression" value="#{bean.someValue}"/>

</e:load>

</h:commandButton>

}}}

Wird ein Scope innerhalt eines bestehenden Scopes geladen, kann es notwendig sein innerhalb des Load-Tags auf den bestehenden Scope zuzugreifen. Dies kann über die Variable scope erfolgen, also zum Beispiel:

{{{

<e:load viewId="/dialog/user-password.xhtml"/>

<f:param name="user" value="#{scope.user}"/>

</e:load>

}}}

Das geladene Popup-Facelet "/popup.xhtml" kann zum Beispiel so aussehen:

{{{

<?xml version="1.0" encoding="UTF-8"?>

<ui:composition xmlns="http://www.w3.org/1999/xhtml"

xmlns:f="http://java.sun.com/jsf/core"

xmlns:h="http://java.sun.com/jsf/html"

xmlns:ui="http://java.sun.com/jsf/facelets"

xmlns:rich="http://richfaces.org/rich"

xmlns:a4j="http://richfaces.org/a4j"

xmlns:t="http://siemens.com/test"

xmlns:app="http://java.sun.com/jsf/composite/app"

xmlns:e="http://java.sun.com/jsf/ext"

xmlns:ext="http://java.sun.com/jsf/composite/ext"

<rich:popupPanel id="popup" show="true" autosized="true" modal="false">

<f:facet name="header">

<h:outputText value="Loaded Popup"/>

</f:facet>

<f:facet name="controls">

<h:form id="controls-form">

<h:commandButton value="X" immediate="true">

<f:ajax/>

<e:unload/>

<e:behavior script="#{rich:component('popup')}.hide(event);"/>

</h:commandButton>

</h:form>

</f:facet>

<h:form id="form">

<h:panelGrid columns="2">

<h:outputLabel for="popupText" value="Popup Text"/>

<h:outputText id="popupText" value="#{bean.popupText}"/>

<h:outputLabel for="someParam" value="Some Param"/>

<h:outputText id="someParam" value="#{scope.someParam}"/>

<h:outputLabel for="someExpression" value="Some Expression"/>

<h:inputText id="someExpression" value="#{scope.someExpression}"/>

</h:panelGrid>

<ext:buttons>

<h:commandButton id="save" value="Save" action="#{bean.save}">

<f:ajax execute="@form"/>

<e:unload/>

<e:behavior script="#{rich:component('popup')}.hide(event);"/>

</h:commandButton>

<h:commandButton id="cancel" value="Cancel" immediate="true">

<f:ajax/>

<e:unload/>

<e:behavior script="#{rich:component('popup')}.hide(event);"/>

</h:commandButton>

</ext:buttons>

</h:form>

</rich:popupPanel>

</ui:composition>

}}}

Hier ist auch das Unload-Tag enthalten:

{{{

<h:commandButton value="X">

<f:ajax/>

<e:unload/>

<e:evaluate script="#{rich:component('popup-panel')}.hide(event);"/>

</h:commandButton>

}}}

Es handelt sich wie beim Unload-Tag um einen commandButton, der mit AJAX-Tag erweitert wurde. Im Gegensatz zum Load-Tag braucht beim Unload-Tag nicht zwingend die Scope-Id angegeben werden. Für den Fall dass der Unload-Tag innerhalb eines Scopes auftritt, wird automatisch dieser Scope verwendet. Damit vereinfachen sich unter anderem Close- und Save-Buttons.

Der Load-Tag unterstützt eine Action, innerhalb derer bereits der neue Scope verfügbar ist.

{{{

<h:commandButton value="Create user">

<f:ajax/>

<e:load viewId="/dialog/createUser.xhtml" action="#{userController.create}/>

</h:commandButton>

}}}

__Erklärung:__ Würde man die Action im <h:commandButton> aufrufen, wäre der Scope nicht verfügbar, damit könnten auf die Werte aus dem Scope nicht zugegriffen werden.

__Hinweis:__ Falls die Tags innerhalb des Scopes Header-Resourcen installieren, werden diese Transparent nachgeladen. Das bedeutet zunächst eine schlanke Web-Seite, die schnell geladen werden kann. Einzelne CSS-Dateien, Scripts und Images werden erst bei Bedarf nachgeladen.

Für seltene Fälle unterstützt der Load-Tag auch eine Unload-Action. Die Managed-Beans können über eine @PreDestroy-Annotation feststellen, wenn der Scope beendet wird und dort den entsprechenden Code ausführen. Bei kleinen Scopes mächte man in einigen Fällen keinen eigenen Controller, sodass diese Methode verwendet werden kann.

{{{

<e:load viewId="/dialog/createUser.xhtml" action="#{scope.projectScope.addCascade(scope)}"

unloadAction="#{scope.projectScope.removeCascade(scope)}">

<f:param name="projectScope" value="#{projectScope}"/>

</e:load>

}}}

__Erklärung:__ Dem Scope "projectScope" wird ein Fenster "Create User" aufgeschaltet. Mit der action wird eine Cascade installiert, die beim Schließen des Project Scope den neuen Create User Scope ebenfalls schließt. Die Unload Action entfernt diese Cascade wieder.

Ein Scope kann auch aus einem JAR geladen werden, wenn er in META-INF/resources liegt:

{{{

<e:load viewId="scopes.xhtml" library="debug"/>

}}}

!!Scopes entladen

Neben dem Tag <e:unload> können Scopes auch mit #{scopes.unload(id)} entladen werden und innerhalb des Scopes selbst mit #{scope.unload}. Dies ist praktisch, um zum Beispiel ohne Formular einen Close-Butten auf einem Popup zu platzieren:

{{{

<p:dialog id="dialog" header="#{messages['rule.edit']}" visible="true">

<f:ajax event="close" listener="#{scope.unload}"/>

<h1>Content</h1>

</p:dialog>

}}}

!!Java-Code

Wird innerhalb des XHTML eine Java-Action aus einem Scope aufgerufen, so ist der Scope zugreifbar durch Scopes.getScope()

Ein Klasse im Custom-Scope kann so aussehen:

{{{

@ManagedBean

@CustomScoped("#{scopes.scope}")

public class FieldEdit implements Serializable {

private static final long serialVersionUID = 1L;

@ManagedProperty("#{scopes.scope.value}")

private Field field;

public Field getField() {

if (field == null)

field = new Field();

return field;

}

public void setField(Field field) {

this.field = field;

}

public void save() {

ProcessService.saveField(field);

Event.instance().raise("workflow." + field.getWorkflow().getId() + ".fieldList.change");

Resource.addMessage(

FacesMessage.SEVERITY_INFO, "field.save.success", field.getName(), field.getWorkflow().getName());

Scopes.instance().getScope().unload();

}

}}}

Hier spart die save-Methode eine Menge Code, bei erfolgreicher Durchführung wird durch Scopes.instance().getScope().unload() der Scope beendet, die enthaltenen Daten freigegeben zur Garbage Collection sowie ein dahinerliegendes Popup geschlossen. Es sind keine weiteren XHTML-Elemente erforderlich, da der Render-Event dadurch ebenfalls erzeugt wird.

!!Spring

Der Scope kann auch zusammen mit Spring-Scopes verwendet werden, dabei ist die Konfiguration weiter unten in diesem Dokument zu beachten.

{{{

@Component

@Scope(Scopes.SCOPE_NAME)

public class SomeBean {

...

}

}}}

__Erklärung:__ Die Beans werden also bei Bedarf instantiiert und im JSF-Scope abgelegt. Dadurch kann ein Dialog- oder Unterdialog abgearbeitet werden. Am Ende des [Workflow] wird der Scope samt Inhalt wieder abgeräumt und der Garbage-Collection zugeführt. Dies ist sehr effizient implementiert, die Anwendung profitiert durch Verwenden von <e:load>, <e:unload> und <e:scope> von einer spürbaren Vereinfachung.

!!Verschachtelte Scopes

Der Code demonstriert das Iterieren und Schachteln von Scopes:

{{{

<c:forEach begin="1" end="3" var="index">

<e:scope id="scope-#{index}" load="true">

<f:param name="scopeVar" value="scope-value-#{index}"/>

<h:outputText value="Inside: #{scope.id}, #{scope.scopeVar}"/>

<e:scope id="nested" load="true">

<f:param name="innerVar" value="value-#{index}-#{scope.parent.scopeVar}"/>

<h:outputText value="Nested: #{scope.innerVar}"/>

</e:scope>

</div>

</e:scope>

</c:forEach>

}}}

In der Praxis würde man eher Facelets laden mit dem Load-Tag und kein festes Attribut load="true" angeben.

!!Component Injection

Gelegentlich kann der Wunsch bestehen, einzelne Elemente in eine Scope-Komponente zu injecten. Dieses Design-Pattern kann durch die den Tag <e:insert> erreicht werden, auch im Zusammenhang mit <c:forEach> bzw. <e:for>.

Im folgenden Beispiel wird ein Save-Button einem Dialog hinzugefügt:

{{{

<app:editResource value="#{processDetails.process.title}"

rendered="#{facesContext.externalContext.isUserInRole('ROLE_MANAGER')}">

<h:form id="resource-form">

<ext:buttons>

<h:commandButton value="#{messages['save']}" action="#{processDetails.save}">

<f:ajax/>

<e:unload scopeId=":textList"/>

</h:commandButton>

</ext:buttons>

</h:form>

</app:editResource>

}}}

Im Tag <app:editResource>:

{{{

<e:load scopeId=":textList">

<f:param name="resource" value="#{cc.attrs.value}"/>

<f:param name="children" value="#{cc.children}"/>

</e:load>

}}}

Und schließlich im Scope:

{{{

<c:forEach items="#{scope.children}" var="child">

<h:panelGroup style="padding: 5px 5px 0 0;" rendered="#{child.rendered}">

<e:insert component="#{child}"/>

</h:panelGroup>

</c:forEach>

}}}

__Erklärung:__ Die Composite-Children werden durch die EL-Expression cc.children als Scope-Variable übergeben und durch den Insert-Tag eingefügt. Natürlich kann der Zwischenschritt über die Composite-Component auch entfallen. In diesem Fall können die Children zum Beispiel auch mit der EL-Expression component.children übergeben werden.

__Hinweis:__ Die so eingefügten Komponenten werden an ihrer Ursprungsstelle ausgeführt, was sich insbesondere bei Action-Methoden auswirken kann, wenn auf Variablen zugegriffen wird. Component-Injection sollte daher nur für einfache Elemente verwendet werden, da es schnell zu unsauberen Code führen kann.

__Alternative:__ Als saubere Lösung für Scopes, die in unterschiedlichen Varianten auftreten, kann der Inhalt des Scopes in eine XHTML-Datei ausgelagert werden. Dann werden mehrere Scopes mit den entsprechenden Varianten aufgebaut.

!!Recovering

In JSF führen Exceptions in der Regel zu einem Fehler auf einer Seite, die Seite kann nicht dargestellt werden. Oft wird auf eine Fehlerseite umgeleitet. Bei komplexen Seiten, etwa bei vielen Popups, ist dieses Verhalten nicht befriedigend, da erhebliche Daten verloren gehen können.

Scopes unterstützen daher Recovering, Standardverhalten ist den betreffenden Scopes zu schließen, wenn darin eine Exception ausgelöst wurde. Zusätzlich enthält jeder Scope ein Attribut, an welches eine Method-Expression gebunden werden kann mit der Signatur boolean recover(java.lang.Throwable). Damit kann eine zusätzliche Methode angegeben werden, um ein Problem in diesem Scope zu lösen. Wurde das Problem gelöst, kann true zurückgegeben werden um den Standard-Recovery zu unterdrücken.

!!Scope Behaviors

Die Scope-Komponente kennt folgende Behaviors:

* __onload:__ JavaScript Code der beim Laden des Scopes ausgeführt wird.

* __onunload:__ JavaScript Code der beim Schließen des Scopes ausgeführt wird.

{{{

<e:scope id="test" recover="testBean.recover">

...

</e:scope>

}}}

!!Onunload Tag

Manchmal ist es geschickter, Code für den Unload eines Scopes in den entsprechenden Components zu platzieren. Das Cleanup von DOM-Teilen bleibt also zusammen bei der betreffenden Komponente. Dazu gibt es den Tag <e:onunload>:

{{{

<e:onunload script="cleanUpSomeElements();"/>

}}}

!!Scope Hierarchie

Ein Scope kann direkt aus der Page geöffnet werden oder aus einem anderen Scope heraus. Im letzten Fall wird im neuen Scope der Parent Scope eingetragen und dem Parent Scope eine Cascade-Anweisung.

!Cascading

Wird der Parent Scope geschlossen, werden automatisch alle daraus geöffneten Scopes mit geschlossen. Cascading kann unterbunden werden, wenn bei beim Load-Tag cascade="false" angegeben wird:

{{{

<e:load viewId="/dialog/test.xhtml" cascade="false"/>

}}}

!Programmatisches Cascading

Scopes können auch manuell verlinkt werden, indem die Methode scope.addCascade(Scope scope) aufgerufen wird. Das Cascading kann durch scope.removeCascade(Scope scope) wieder entfernt werden. Dies ist dann interessant, wenn Popup-Fenster über einen Umweg auf andere aufgeschaltet werden.

Die Scope-Liste gebraucht diesen Mechanismus:

{{{

<e:load scopeId="edit-#{element.id}" viewId="/dialog/object.xhtml"

action="#{scope.scope.addCascade(scope)}"

unloadAction="#{scope.scope.removeCascade(scope)}">

<f:param name="scope" value="#{element}"/>

<f:param name="name" value="#{element.id}"/>

<f:param name="object" value="#{element}"/>

</e:load>

}}}

!!Debugging

Wie in der Session oder anderen Scopes, können im Custom-Scope viele Werte liegen. Zu Debugging-Zwecken kann es interessant sein, in die Scopes zu sehen. Das Scope-Debugging ist mit Primefaces implementiert. Das heißt, wenn sie die Scope-Debug-Views verwenden wollen, brauchen sie Primefaces im Projekt.

Der Einstieg erfolgt durch:

{{{

<e:load viewId="scopes.xhtml" library="debug"/>

}}}

Das sieht dann so aus:

[JSF Ext/scope debug.PNG]

At line 194 added 25 lines

!!Properties Resources

In [JSF] können Properties-Dateien definiert werden, die entsprechend der Endung im Namen für die Internationalisierung verwendet werden können. Um auch aus dem Java-Code darauf zugreifen zu können, gibt es die Klasse com.intersult.jsf.messages.Resource:

||Methode||Beschreibung

|getString|Den Resource-String zurückgeben. Falls nicht vorhanden, wird ein Dummy zurückgegeben.

|getStringNull|Den Resource-String zurückgeben. Falls nicht vorhanden, wird null zurückgegeben.

|getStringVariant|Eine Variante eines Resource-Strings zurückgeben.

|getFormatVariant|Eine formatierte Variante eines Resource-Key zurückgeben.

|getFormat|Einen formatierten Resource-String zurückgeben.

|addMessage|Eine globale Faces-Message aus einem Resource-Key hinzufügen.

|addMessageToComponent|Eine Faces-Message aus einem Resource-Key zu einer Komponente hinzufügen.

|getMessage|Eine Faces-Message aus einem Ressource-Key erzeugen

|enumFormat|Einen formatierten Resource-String für ein Enum zurückgeben.

|enumFormatVariant|Eine Variante eines formatierten Resource-String für ein Enum zurückgeben.

|enumString|Einen Resource-String für ein Enum zurückgeben.

|enumList|Eine Liste mit Enums zurückgeben.

|enumStringList|Eine Liste mit Enum-Strings zurückgeben.

|enumStringListVariant|Eine Liste mit Varianten von Enum-Stringe zurückgeben.

|enumSelectItems|SelectItems für das Befüllen von JSF-Elementen (Dropdowns etc.) zurückgeben

|enumSelectItemsType|SelectItems für einen Enum-Type zurückgeben.

|enumSelectItemsTypeVariant|SelectItems für Varianten eines Enum-Types zurückgeben.

|enumSelectItem|Ein einzelnes SelectItem erzeugen.

|abbreviate|Einen String für die Oberfläche abkürzen.

|replaceHtml|HTML-Sonderzeichen ersetzen.

At line 1,156 changed one line

@Value("#{scope.rule}")

@ScopeValue

At line 1,278 changed one line

<h:outputLabel for="name" value="Name"/>

<h:outputLabel for="name:name" value="Name"/>

At line 451 added 7 lines

!!Validation Messages

Die ValidationException von JSF nimmt den String direkt. [JSF Ext] stellt eine Ableitung davon zur Verfügung, mit der ein Resource-Key übergeben werden kann. Damit ist eine Internationalisierung möglich:

{{{

throw new ValidatorResourceException("user.unique.name");

}}}

At line 1,388 changed one line

|mimeType|Enthält den vom Browser gesendeten Mime-Type.

|mimeType|String|Enthält den vom Browser gesendeten Mime-Type.

At line 529 added 129 lines

__Achtung:__ Es gibt Servlet-Filter, welche den InputStream des HttpServletRequest nicht korrekt durchreichen. Sie sollten diese Filter ausschalten, sonst kann der File-Upload nicht an die entsprechende Datei herankommen.

!!!Utilities und Tools

[JSF Ext] enthält einige Instrumente zur Unterstützung der Entwicklung von weiteren Tool- und Component-Bibliotheken für [JSF].

!!Document Writer

[JSF] bietet die Möglichkeit zum Einsatz von Render-Kits, also eine alternative Darstellung der XHTML-Seiten. Der Standard-Writer schreibt allerdings HTML-Code direkt als Stream. Für Anwendung wie z.B. PDF generieren wäre sinnvoll, auf den Document-Tree zuzugreifen. Dafür kann der Document Writer eingesetzt werden:

{{{

DocumentWriter writer = new DocumentWriter(context.getResponseWriter(), "application/pdf");

context.setResponseWriter(writer);

}}}

__Hinweis:__ Für die Integration in den JSF Lifecycle sind noch einige andere Dinge zu beachten. Dies zu erklären wäre zu umfangreich für diese Dokumentation, dies kann in der Dokumentation für JSF nachgelesen werden.

!!XML Rendering

Soll die Seite direkt als XML gerendert werden, bietet [JSF Ext] noch eine weitere Kapselung des Document Writer an. Die Methode Jsf.renderViewXml kann direkt aus einem HTTP-Request ein XHTML-Document rendern, ohne über das JSF-Servlet zu gehen.

Dies kann nützlich sein, wenn der Document-Tree weiter verarbeitet werden soll, zum Beispiel zum Generieren anderer Ansichten.

__Hinweis:__ Für PDF steht das [PDF Renderkit] zur Verfügung. Andere Browser- und Download-Ansichten sollten generell in der Form eines Renderkit zur Verfügung gestellt werden. Für weitere Unterstützung beraten wir Sie gerne.

!!Unwrapping FacesWrapper

Vor allem seit [JSF 2|JSF2] wurde die faces-config.xml weiter ausgebaut. JSF-Komponenten können viele JSF-Klassen wrappen, indem sie das Interface FacesWrapper implementieren. Einige Klassen haben diesen Wrapper bereits implementiert, sodass sie nur noch abgeleitet werden brauchen. [JSF Ext] enthält noch weitere Wrapper im Package com.intersult.jsf.wrapper.*, wie zum Beispiel ViewRootWrapper oder ValueExpressionWrapper, die das Implementieren von Komponenten unterstützen können.

Dahinter liegender Sinn ist das Zusammenspiel mehrerer Faces-Erweiterungen nebenher. Die Wrapper werden in unbestimmter Reihenfolge aufgerufen, sodass jede betroffene Klasse prüfen kann, ob sie etwas zu tun hat. Falls nicht, gibt sie den Aufruf einfach an die Wrapped Instance weiter.

Einen Nachteil gibt es bei der Sache: Hat man FacesWrapper erst einmal abgeleitet, kommt man meist nur mehr sehr schwierig an die eigene Klasse ran. Abhilfe schafft die Methode Jsf.unwrap, mit der man seine eigenen (oder auch fremde) Klassen in der Wrapper-Kette findet:

{{{

ExtFacesContext extContext = Jsf.unwrap(parent, ExtFacesContext.class);

}}}

!!Expression Analyzer

Methoden um Referenzen auf EL-Expressions zu bekommen, Expressions umzuwandeln. Wird gebraucht, um Validierungen an der Oberfläche vornehmen zu können.

{{{

ValueReference reference = ExpressionAnalyzer.getReference(expression, context.getELContext());

Object base = reference.getBase();

}}}

!!Interpolator

Mit dem Interpolator können EL-Expressions innerhalb eines Strings ersetzt werden.

||Methode||Bedeutung

|interpolate|Einen String interpolieren.

|evaluate|Eine Expression evaluieren.

|create|Eine neue EL-Expression anlegen.

|createMethodExpression|Eine Method-Expression erzeugen.

|createValueExpression|Eine Value-Expression erzeugen.

|createLiteral|Eine Literal-Expression erzeugen.

|coerce|Eine Typumwandlung vornehmen.

|setVariable|Eine Variable setzen.

|restoreVariable|Eine Variable wiederherstellen.

|action|Eine Action-Expression ausführen.

|converterFor|Einen Converter für eine bestimmte Klasse holen.

!!IO Utils

Methoden für das Schreiben, Lesen und Kopieren von Streams:

{{{

IOUtils.copy(binaryStream, outputStream);

}}}

!!!Navigation

[JSF Ext] enthält eine transparente Lösung für das Redirect-After-Submit-Pattern. Am besten arbeitet diese Lösung mit web.xml 3.0 und Application-Servern, wie Tomcat 7, die diesen Standard unterstützen.

__Hintergrund:__ Ohne Redirect-After-Submit wird nach der Navigation auf eine andere Seite in der Browser-URL-Zeile die vorhergehende Seite angezeigt. Des Weiteren wird bei einem Seiten-Request die für den Benutzer oft unverständliche Meldung angezeigt, ob die Seite nochmal abgeschickt werden soll. Ziel des Redirect-After-Submit-Pattern ist beides zu vermeiden.

Redirect-After-Submit wird aktiv, wenn man [JSF Ext] einbindet und web.xml 3.0 verwendet. Alle Page-Submits mit <h:commandButton>, <h:commandLink> etc. werden mit einem Redirect abgeschlossen.

__Ergebnis:__ Nach der Navigation wird die aktuelle URL im Browser angezeigt. Refresh der Seite im Browser kann ohne Rückfrage durchgeführt werden.

__Hinweis:__ Bei einem Redirect geht üblicher Weise der Zustand der Seite verloren. [JSF Ext] nutzt den sogenannten Flash-Scope von [JSF], um dieses Hindernis zu überwinden und auch Faces-Messages über den Redirect zu retten. Daher ist web.xml 3.0 und Tomcat 7 für das saubere Arbeiten erforderlich.

Bei web.xml 2.x und Tomcat 6 kann ein Fallback-Mechanismus verwendet werden, der die View-Id als GET-Parameter an die URL hängt. Dies ist zwar problemlos möglich, jedoch können dann keine "sauberen" URLs mehr produziert werden. Dieses Verhalten kann mit einem Konfigurations-Parameter in der web.xml aktiviert werden:

{{{

<context-param>

<param-name>javax.faces.REDIRECT_AFTER_SUBMIT</param-name>

<param-value>true</param-value>

</context-param>

}}}

!!!Fehler und Exceptions

[JSF Ext] enthält mehrere Mechanismen für das Handling von Exceptions. Grundlage dazu ist der ExtExceptionHandler und eine speziell Ableitung, der AjaxExceptionHandler.

!!AJAX Exception Handler

Der Handler ist dafür verantwortlich, dass Exceptions während eines AJAX-Requests nicht die komplette Seite lahm legen. Eine derartige Exception wird ins Logfile eingetragen und eine Faces-Message dafür generiert.

Dabei existieren zwei Konfigurationsparameter:

||Parameter||Bedeutung

|javax.faces.IGNORE_EXCEPTIONS|Eine durch Kommata separierte Liste von voll qualifizierten Exception-Klassen-Namen, die ignoriert werden sollen. Diese tauchen nicht als Fehler auf. Damit sollte sehr vorsichtig umgegangen werden, weil es zu versteckten Fehlfunktionen in der Applikation führen kann, die später sehr schwer zu finden sein können.

|javax.faces.PASS_EXCEPTIONS|Diese Exceptions werden an den nächsten Exception-Handler durchgelassen. Dies ist für Exceptions sinnvoll, für die man einen eigenen Exception-Handler schreiben möchte oder eine Dritt-Software hat, die diese handeln möchte.

!!Full Request Exception Handler

Wenn kein AJAX-Request vorliegt oder die Exception in javax.faces.PASS_EXCEPTIONS konfiguriert wurde und von keinem anderen Exception-Handler verarbeitet wurde, erreicht sie den ExtExceptionHandler.

Dieser erlaubt das Definieren von Exception-Navigationen in der faces-config.xml:

{{{

<navigation-rule>

<navigation-case>

<from-outcome>org.springframework.security.access.AccessDeniedException</from-outcome>

<to-view-id>/security/login.xhtml</to-view-id>

</navigation-case>

</navigation-rule>

<navigation-rule>

<navigation-case>

<from-outcome>java.lang.Throwable</from-outcome>

<to-view-id>/error.xhtml</to-view-id>

</navigation-case>

</navigation-rule>

}}}

__Erklärung:__ Die erste Navigationsregel leitet alle Fälle von AccessDeniedException auf die View /security/login.xhtml um. Die zweite Regel für Throwable leitet alle Exceptions, die nicht von vorherigen Regeln erfasst wurden auf die View /error.xhtml um.

Die aufgetretene Exception wird dabei in einer Bean namens pageError erfasst:

||Property oder Methode||Bedeutung

|exception|Hier ist die aufgetretene Instanz von java.lang.Throwable enthalten. Dadurch können genauere Informationen über den Fehler angezeigt werden.

|viewId|Hier ist die View-Id gespeichert, bei Bedarf kann diese ebenfalls angezeigt werden.

|init()|Diese Methode kann vor dem Aufbau der Error-Page aufgerufen werden und check ob ein Fehler vorliegt.

|back()|Navigiert zurück auf die Seite auf der der Fehler aufgetreten war, damit der Benutzer weiter arbeiten kann.

!!!Downloads

* [JSF Ext CDI Package|JSF Ext/jsf-ext-cdi.zip]

This page (revision-184) was last changed on 21-Apr-2017 08:27 by Dieter Käppel Top

Übersicht
Startseite
Das Unternehmen
Produkte
Consulting
Referenzen

Jobmarkt
Jobangebote
Profile

Hilfe
Suche
Seitenindex
Letzte Änderungen
Sichere Verbindung

Systeme
Tickets
Jenkins
Nexus
SVN
Email Client

13723 Aufrufe

referenziert von
Application Support
Faces Filter
Intersult Expert
Intersult Produkte
Intersult Taglib
Intersult Unternehmensbewertung
Intersult expert
Intersult taglib
JPA Support
JSF Desktop
JSF Ext
JSF Ext Events
JSF Ext Functions
JSF Ext Push
JSF Ext Scopes
JSF Ext Tags
JSF Spring Integration
JSF2
Jsf desktop
Jsf ext

...and 6 more