JSF Ext Tags
Your trail: JSPWikiJSF Ext TagsDocker

This page (revision-41) was last changed on 04-Sep-2014 13:44 by Dieter Käppel

This page was created on 21-Aug-2013 14:14 by Dieter Käppel

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
41 04-Sep-2014 13:44 35 KB Dieter Käppel to previous

Page References

Incoming links Outgoing links
JSF Ext Tags
JSF Ext Tags

Version management

Difference between version and

At line 1 changed one line
Das Produkt [JSF Ext] enthält eine ganze Reihe von JSF-Tags. Diese werden auf dieser Seite beschrieben.
Das Produkt [JSF Ext] enthält eine Reihe von JSF-Tags. Diese Seite beschriebt die Anwendung der Tags.
At line 3 changed one line
Die Tags <e:load>, <e:unload>, <e:scope> und <e:scopes> werden bei [JSF Ext Scopes] beschrieben.
Ausnahmen:
* Die <e:push> und <e:socket> für AJAX-Push werden in [JSF Ext Push] beschrieben.
* Die Tags <e:load>, <e:unload>, <e:scope> und <e:scopes> werden bei [JSF Ext Scopes] beschrieben.
At line 8 changed one line
!!!Insert Tag
!!!Control Tags
In diesem Abschnitt werden Tags für den Umgang mit Tag Handling und Aufbau der Page beschrieben.
!!Insert Tag
At line 41 changed one line
!!!Behavior-Tag
!!!JavaScript ausgeben
!!Behavior Tag
At line 62 changed one line
!!!Evaluate Tag
!!Evaluate Tag
At line 74 changed one line
Unterschied zwischen Behavior- und Evaluate-Tag:
!!Script Tag
Der Tag <e:script> gibt Scripte beim AJAX-Rendering aus. Es ist keine Kopplung an Behaviors oder Actions erforderlich. Dadurch können Aktionen beim Rendern von Components aufgeführt werden, zum Beispiel ein Highlighting durch JavaScript:
At line 76 changed 4 lines
||||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
{{{
<e:script script="ext.util.flash('some-tag', '#80ff80');"/>
}}}
At line 81 changed one line
!!!AJAX-Tag
!!Output Behavior
Der Tag <e:outputBehavior> gibt das Script anderer Behaviors als Text aus. Dies ist vor allem in Composite-Tags nützlich, die Behaviors unterstützen sollen. Dies ist vor allem bei AJAX-Request nützlich, weil es viel bequemer und robuster ist <f:ajax>, <e:ajax> oder dergleichen zu benutzen anstatt von jsf.ajax.request oder anderen JavaScript-Konstrukten.
Möchte man zum Beispiel einen Composite-Tag schreiben, der am unteren Ende einer Page ein Behavior ausführt, kann das wie folgt geschehen:
{{{
<?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"
>
<cc:interface>
<cc:clientBehavior name="behavior" event="behavior" targets="behavior" default="true"/>
</cc:interface>
<cc:implementation>
<h:outputScript name="util.js" library="ext-js"/>
<script id="#{cc.clientId}" type="text/javascript">
ext.util.addListener(window, 'scroll', function(event) {
var body = event.target.body;
var bottom = body.scrollTop + window.innerHeight;
if (bottom == body.scrollHeight) {
<e:outputBehavior id="behavior"/>
}
});
</script>
</cc:implementation>
</html>
}}}
__Erklärung:__ Der Tag definiert das Behavior "behavior" als Behavior-Parameter. Das übergebene Behavior wird dann an der Stelle des <e:outputBehavior> im JavaScript-Block ausgegeben.
__Hinweis:__ Dieser Tag ist als <ext:onscroll> bereits in [JSF Ext] enthalten.
!!Unterschiede der Tags
Unterschied zwischen Behavior-, Evaluate- und Script-Tag:
||||Behavior||Evaluate||Script
|Zeitpunkt der Ausführung|Direkt durch den Browser-Event|Durch den AJAX-Request an den Browser gesendet|Durch das AJAX-Rendering der Component
|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|Nur beim AJAX-Rendering, nicht beim Aufbau der Seite.
|Anwendungszweck|Steuerung des Browserverhaltens, Ein- und Ausblenden, Fading, dynamische Browserelemente, Client-Behavior|Abwickeln von Server-States, Popups öffnen und Schließen, Submits bestätigen|Spezielle AJAX- und Push-Features, Highlighting, Informationen.
!!!AJAX Tag
At line 84 changed one line
!Sources
!!Sources
At line 104 changed one line
!Action Source
!!Action Source
At line 113 changed one line
!Client-Behaviors
!!Client-Behaviors
At line 176 added 15 lines
!!Request Parameter
Der AJAX-Tag kann auch Request-Parameter übertragen.
{{{
<h:graphicImage name="process.png" library="images/info">
<e:ajax event="click" action="/index.xhtml">
<f:param name="mode" value="AVAILABLE"/>
</e:ajax>
</h:graphicImage>
}}}
__Achtung:__ Die im Value-Attribut verwendeten EL-Expressions werden bereits beim Rendern der View ausgewertet und können möglicher Weise veraltete, nicht gewünschte Werte enthalten. Verwenden sie diese Möglichkeit zur Übergabe von Parametern nur, wenn sie genau wissen, was sie tun.
__Hinweis:__ In den meisten Fällen ist es angebraucht, die Werte mit <e:set> (bzw. <f:setPropertyActionListener>) zu setzen, weil die entsprechenden EL-Expressions erst beim Drücken des Knopfs ausgewertet werden.
At line 139 changed one line
!!!Attribute-Tag
!!!Attributes und Paramters
!!Attribute Tag
At line 156 changed one line
!Attribute-Behaviors
!!Attribute-Behaviors
At line 167 changed one line
!Zusammengesetzte Attribute
!!Zusammengesetzte Attribute
At line 180 changed one line
!Part-Attribute
!!Part Attribute
At line 197 changed one line
!Style-Attribute
!!Style Attribute
At line 210 changed one line
!!!Reference-Tag
!!Method Parameters
Für Zwecke wie dem Laden eines Scopes mit <e:load> können Parameter mit <f:param> übergeben. Dies unterstützt allerdings nur Value-Expressions und keine Method-Expressions. Mit dem Tag <e:method-param> können auch Methoden übergeben werden. Dies geht allerdings nur, wenn EL 2.0 unterstützt wird.
{{{
<e:load viewId="/dialogs/someDialog.xhtml">
<e:method-param name="action" value="#{test.action}"/>
</e:load>
}}}
Damit können parameterisierte Dialoge erstellt werden, deren Action-Elemente bestimmte Methoden ausführen.
__Erklärung:__ Der Aufruf findet dann über #{scope.action.invoke} statt. Die eigentliche Methode wird im EL-Scope als Value abgelegt und enthält die Methode "invoke", mit der die Methode dann aufgerufen werden kann.
__Hinweis:__ Der Aufruf kann auch mit Parametern erfolgen, wenn #{scope.action.invoke(param)} verwendet wird.
Soll eine derart übergebene Method-Expression weitergereicht werden, kann dies als normaler <f:param> erfolgen:
{{{
<h:commandLink value="Nested">
<f:ajax/>
<e:load scopeId="select" viewId="/dialog.xhtml">
<f:param name="action" value="#{scope.action}"/>
</e:load>
</h:commandLink>
}}}
!!!Utility Tags
!!Reference-Tag
At line 215 changed one line
!!!New-Tag
!!New-Tag
At line 234 changed one line
!!!Set-Tag
!!Set-Tag
At line 270 changed one line
!!!Label
!!Label
At line 286 changed 2 lines
!!!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.
Darüber hinaus können die Klassen requiredStyleClass und notRequiredStyleClass auch manuell festgelegt werden, indem diese als Attribut angegeben werden.
At line 289 changed 32 lines
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
!!Move Listener
At line 338 changed one line
!!!Init-Tag
!!Init-Tag
At line 382 changed one line
!!!Otherwise-Tag
!!Otherwise-Tag
At line 401 changed 34 lines
!!!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.
!!!Async-Tag
!!Async-Tag
At line 478 changed 2 lines
!!!Socket-Tag und AJAX-Push
Mit sogenannten Push können Informationen aktiv an den Browser übertragen werden. Vor allem ist es dadurch möglich, eine Vielzahl von Benutzern gleichzeitig über ein Ereignis zu informieren.
!!For-Tag
Der Tag <e:for> ist ein Schleifen-Tag mit erweiterten Möglichkeiten. Er kombiniert die Naming-Container Eigenschaft von <ui:repeat> mit der Flexibilität von <c:forEach> und ist darüber hinaus noch angenehm kurz.
At line 481 changed one line
Der Tag <e:socket> nutzt Web-Sockets um Browser-Push durchzuführen. Dies ist eine sehr effiziente Implementierung mit geringer Verzögerung zwischen dem Versenden der Nachricht und dem Eintreffen im Browser, sowie Netzwerk und Ressourcen schonend. Dies ist möglich, wenn der Web-Server den Web-Standard 3.0 beherrscht (z.B. ab Tomcat 7). Sind Web-Sockets nicht verfügbar aufgrund eines Web-Servers kleiner als 3.0, weil der Browser dies nicht beherrscht oder ein dazwischen liegender Proxy es nicht unterstützt, wird die Comet-Engine verwendet, die Long-Polling durchführt.
Folgender XHTML-Code erzeugt eine Reihe von Knöpfen:
At line 483 removed 2 lines
Zur Verwendung wird einfach das Atmosphere-Framework in die pom.xml konfiguriert:
At line 486 changed 5 lines
<dependency>
<groupId>org.atmosphere</groupId>
<artifactId>atmosphere-runtime</artifactId>
<version>2.0.0.RC3</version>
</dependency>
<h:form id="form">
<e:for id="for" value="#{table.list}" var="element">
<h:commandButton id="button" value="#{element.text}" action="#{element.action}">
<f:ajax/>
</h:commandButton>
</e:for>
</h:form>
At line 493 changed one line
__Hintergrund:__ Es wird das Atmosphere-Framework verwendet, das mit allen gängigen Application-Servern und Browsern zusammen arbeitet.
Das Attribut value kann dabei durch eine Collection, Map, Array, einzelnes Element oder einen Null-Wert versorgt werden.
At line 495 changed one line
Die Anwendung des Sockets sieht zum Beispiel so aus:
Mit dem Attribut test können Elemente aus der Schleife gefiltert werden, entsprechend dem Syntax von <c:if test="...">.
At line 497 changed 5 lines
{{{
<e:socket channel="/test">
<f:ajax render=":push-form:chat"/>
</e:socket>
}}}
!!Vertical Text Tag
Vertikaler Text, also um 90° gedrehter Text kann in einigen Fällen sehr hilfreich sein. Zum Beispiel um Platz zu sparen beim Beschriften von Header in Tabellen. Die Browser rendern Anweisungen für vertikale CSS-Anweisungen nur sehr uneinheitlich, wenn überhaupt.
At line 503 changed one line
Auf der Java-Seite wird der Socket dann so angesprochen:
Daher bietet [JSF Ext] einen Tag für das Rendern von vertikalen Text:
At line 506 changed one line
PushContext.instance().push("/test");
<e:vertical-text value="Hello World!" fontSize="16"/>
At line 509 changed one line
__Hinweis:__ Die Push-Funktionalität befindet sich momentan in der Entwicklung. In Zukunft werden weitere Funktionalitäten hinzukommen.
||Attribut||Bedeutung
|fontSize|Die Größe des Schriftsatz in Point (pt)
|width|Breite der gerenderten Grafik in Pixel
|height|Höhe der gerenderten Grafik in Pixel
|fontName|Name des Fonts
|color|Farbe der Schrift
At line 511 changed one line
Wird ein Load-Balancer verwendet, sind die Web-Sockets zu beachten. Bei Apache werden folgende Proxy-Einträge vor der eigentlichen Applikation gebraucht:
!!Facet Tag
Dem Standard Tag <f:facet> fehlt leider das Attribut rendered. Man kann auch kein <c:if> herum wrappen. Bei Tabellen löst beispielsweise bereits der leere Tag "header" das Rendern des Headers aus. Der Tag <e:facet> implementiert dieses Attribut.
At line 513 changed 4 lines
{{{
ProxyPass /<context-path>/faces/javax.faces.resource/<channel> ws://<ziel>/<context-path>/faces/javax.faces.resource/<channel>
ProxyPassReverse /<context-path>/faces/javax.faces.resource/<channel> ws://<ziel>/<context-path>/faces/javax.faces.resource/<channel>
}}}
!!Embed Tag
Einige Zeit lang war Portlet das Stichwort für verteilte Web-Anwendungen. Leider hat sich die Implementierung als wenig praktikabel erwiesen, daher sind viele Firmen wieder davon abgerückt.
At line 518 changed one line
__Erklärung:__ Die Web-Socket-Protokolle WS werden vor den eigentlichen Proxy-Einträgen für die Application abgefangen und mit dem WS-Protokoll umgeleitet. In Apache 2.4 steht dafür das Modul mod_proxy_wstunnel.so zur Verfügung.
Eine einfachere Lösung für verteilte Anwendungen ist das Einbetten von Inhalten mit dem Tag <e:embed src="...">. Die Inhalte können vom gleichen Server, der gleichen Anwendung oder einer ganz anderen Quelle kommen. Da mit IFrames gearbeitet wird, ist nicht einmal [JSF] erforderlich oder die gleichen Komponentenbibliotheken.
At line 520 changed 2 lines
!!!For-Tag
Der Tag <e:for> ist ein Schleifen-Tag mit erweiterten Möglichkeiten. Er kombiniert die Naming-Container Eigenschaft von <ui:repeat> mit der Flexibilität von <c:forEach> und ist darüber hinaus noch angenehm kurz.
!!!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.
At line 523 changed one line
Folgender XHTML-Code erzeugt eine Reihe von Knöpfen:
Die alte Implementierung über Render-Attribute führt zu folgenden Verbesserungswünschen:
At line 555 added 6 lines
* __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:
At line 526 changed 7 lines
<h:form id="form">
<e:for id="for" value="#{table.list}" var="element">
<h:commandButton id="button" value="#{element.text}" action="#{element.action}">
<f:ajax/>
</h:commandButton>
</e:for>
</h:form>
Event.instance().raise(EVENT_LOGIN, authentication.getPrincipal());
At line 535 changed one line
Das Attribut value kann dabei durch eine Collection, Map, Array, einzelnes Element oder einen Null-Wert versorgt werden.
Dadurch werden Bereiche neu gerendered:
At line 537 removed 5 lines
Mit dem Attribut test können Elemente aus der Schleife gefiltert werden, entsprechend dem Syntax von <c:if test="...">.
!!!Method Parameters
Für Zwecke wie dem Laden eines Scopes mit <e:load> können Parameter mit <f:param> übergeben. Dies unterstützt allerdings nur Value-Expressions und keine Method-Expressions. Mit dem Tag <e:method-param> können auch Methoden übergeben werden. Dies geht allerdings nur, wenn EL 2.0 unterstützt wird.
At line 543 changed 3 lines
<e:load viewId="/dialogs/someDialog.xhtml">
<e:method-param name="action" value="#{test.action}"/>
</e:load>
<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>
At line 548 changed one line
Damit können parameterisierte Dialoge erstellt werden, deren Action-Elemente bestimmte Methoden ausführen.
__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.
At line 550 changed one line
__Achtung:__ Method-Parameters können nur mit EL-API 2.0 verwendet werden. Dies bedeutet auch, dass sie nicht mit einer EL-Implementierung 2.0 verwendet werden können, auch wenn diese auf EL-API 1.0 basiert, wie die JBoss-Implementierung.
__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 552 changed one line
!!!Action Component
!!!Action Support
!!Action Tag
At line 564 changed 2 lines
!!!AJAX Push
[JSF Ext] arbietet optional mit AJAX Push. Damit können über WebSockets oder Long-Polling Daten direkt an den Browser übertragen werden. Das Atmosphere-Framekwork verwaltet am Server die Verbindungen zu den Clients, sodass nur noch über einen sogenannten Channel kommuniziert werden braucht.
!!Action Context Tag
In [JSF] ist es vorgesehen, dass beim Ausführen einer Action-Methode die ausführende Komponente auf dem Component-Stack gepushed wird. Das bedeutet unter anderem, dass die Komponente mit UIComponent.getCurrentComponent(context) abgefragt werden kann. Dies ist wichtig, wenn man mit <f:attribute> gesetzte Werte abfragen möchte.
At line 567 changed one line
Dazu ist folgende Dependency zum Projekt hinzuzufügen:
Der Workaround besteht im Wrappen des Tags <e:actionContext> um die eigentliche Action-Source:
At line 570 changed 5 lines
<dependency>
<groupId>org.atmosphere</groupId>
<artifactId>atmosphere-runtime</artifactId>
<version>2.1.0-beta1</version>
</dependency>
<p:treeTable id="table" value="#{cc.attrs.value}" var="node">
<p:column>
<e:actionContext>
<p:autoComplete ...>
<f:attribute name="param" value="#{node.someValue}"/>
</p:autoComplete>
</e:actionContext>
</p:column>
</p:treeTable>
At line 577 changed one line
__Hinweis:__ Das Feature ist voll funktional, befindet sich noch im Beta-Stadium, die Version kann sich daher gelegentlich ändern.
__Erklärung:__ Bei der Primefaces Tree-Table wurde offenbar vergessen der Component-Push
At line 579 changed 2 lines
!!Der Socket-Tag
Dies ist die direkteste Variante, Push in [JSF] zu integrieren. Dazu wird einfach ein sogenannter Socket in die XHTML-Seite integriert:
!!!Composite Tags
[JSF Ext] enthält auch bereits einige Composite Tags, diese sind unter dem Namespace xmlns:ext="http://java.sun.com/jsf/composite/ext" verwendbar.
At line 618 added 7 lines
!!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:
At line 583 changed 3 lines
<e:socket channel="/test">
<f:ajax render=":push-form:chat"/>
</e:socket>
<ext:busyPointer/>
At line 588 changed one line
__Hinweis:__ In vielen Fällen reicht die reine Benachrichtigung des Client aus, weil dieser dann per AJAX-Call eine Server-Anfrage startet. Dies bietet den Vorteil, dass die Session und der FacesContext des entsprechenden Benutzers verfügbar ist.
Optional kann das Attribut cursor angeben werde, das per default auf "wait" gesetzt ist.
At line 590 changed one line
Die Socket-Component unterstützt folgende Attribute und Behaviors:
!!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.
At line 592 changed 6 lines
||Attribut||Beschreibung
|channel|Das Attribut wird benötigt und beschreibt den Kommunikationskanal zum Server. Indem der Server diesen Channel informiert, wird im Browser eine Nachricht ausgeliefert. Die Besonderheit am Channel ist, dass dieser von beliebig vielen Browsern d.h. eingeloggten Benutzern abonniert werden kann. Der Server braucht daher nicht zu wissen, wieviele Clients überhaupt die Nachricht empfangen werden.
|onopen|Der Event wird beim Öffnen des Channels ausgelöst. Der Client weiß so immer, ob er verbunden ist oder nicht. Dadurch kann dem Nutzer auch ein Verbindungsstatus angezeigt werden.
|onclose|Das Gegenstück zu onopen, wird aufgerufen, wenn die Verbindung abbricht. Im normalen Produktivbetrieb wird diese Methode nur in Ausnahmefällen aufgerufen.
|onmessage|Dies ist der eigentliche Push-Aufruf. Wenn am Server PushContext.push() aufgerufen wird, wird am Client dieses JavaScript-Behavior ausgelöst.
|onerror|Hier kann eine Fehlerbehandlung hinzugefügt werden, zum Beispiel dem Benutzer angezeigt werden, wenn ein Problem mit der Verbindung auftaucht.
Eine Lösung ist der Tag <ext:mouse-visibility>:
At line 599 changed 2 lines
!!Push-Context
Auf der Server-Seite gibt es die Klasse com.intersult.jsf.push.PushContext. Um eine Nachricht zu einem Tag <e:socket channel="/test"> zu schicken, wird hier ein entsprechender Methodenaufruf durchgeführt:
{{{
<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>
}}}
At line 650 added 5 lines
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.
!!Onscroll Tag
In den letzten Jahren ist das automatische Nachladen von Content modern geworden, wenn die Web-Seite am unteren Ende angelangt ist. Dies lässt sich leicht mit dem Tag <ext:onscroll> realisieren:
At line 603 changed one line
PushContext.instance().push("/test");
<ext:onscroll>
<e:ajax action="#{dashboard.more}" render=":dashboard-form:transaction-list:list"/>
</ext:onscroll>
At line 606 changed 2 lines
!!Push-Parameter
Optional kann der Aufruf auch mit einem Parameter erfolgen, der wird dann JSON-Serialisiert und an den Client übertragen:
__Erklärung:__ Der Tag führt das Behavior <e:ajax/> aus, sobald ans untere Ende der Page gescrollt wird.
At line 663 added 3 lines
!!!Resource Link
JSF-Resources können mit <h:outputStylesheet> und <h:outputScript> ausgegeben werden, mit <h:graphicImage> als Image angezeigt. Einige weitere Tags unterstützen die Attribute "name" und "library". Darüber hinaus gibt es die Möglichkeit, Resource-URLs mit
At line 610 changed one line
PushContext.instance().push("/test", parameter);
#{resource['<library>:<name>']}
At line 613 changed one line
Auf der Client-Seite kann der Parameter dann wie folgt entgegen genommen werden:
zu erzeugen oder ganz zu Fuß mit
At line 616 changed one line
<e:socket channel="/test" onmessage="alert(response.responseBody);">
#{request.contextPath}/faces/javax.faces.resource/<name>?ln=<library>
At line 675 added 90 lines
Möchte man einen Link erzeugen vom Schema <a href="...">, bietet [JSF Ext] eine schönere Lösung:
{{{
<e:resourceLink name="<name>" library="<library">
<h:outputText value="Some link"/>
</e:resourceLink>
}}}
__Hinweis:__ Wie der normale <h:outputLink> unterstützt <h:resourceLink> ebenfalls Parameter vom Typ <f:param>. Des Weiteren ergänzt sich der Link gut mit [Resource Provider|JSF Ext#Resource Provider]
!!!Faces Messages
Das Rendern von Faces Messages braucht üblicher Weise eine explizite Rendering Message. Wird es vergessen, kann der Benutzer nicht erkennen, welches Feld falsch eingegeben wurde.
!!Einfache Message
[JSF Ext] stellt daher selbst rendernde Faces-Messages zur Verfügung als Tag <ext:message>.
!!Severity Tag
Oft sind Seiten komplex aufgebaut und Steuerelemente versteckt. Dafür gibt es den Tag <ext:severity prefix="...">. Dieser Zeigt ein Severity-Icon an für alle Messages mit einem bestimmten Prefix, das heißt für einem Nameing-Container untergeordnete Components.
Der Severity-Tag ist eine Composite Component mit folgender Implementierung:
{{{
<h:panelGroup id="messages" style="#{cc.attrs.style}" styleClass="#{cc.attrs.styleClass}">
<e:render id="render" for=":#{cc.attrs.prefix}:*"/>
<h:graphicImage name="info.png" library="images/message"
rendered="#{e:severity(cc.attrs.prefix) == 'INFO'}"/>
<h:graphicImage name="warn.png" library="images/message"
rendered="#{e:severity(cc.attrs.prefix) == 'WARN'}"/>
<h:graphicImage name="error.png" library="images/message"
rendered="#{e:severity(cc.attrs.prefix) == 'ERROR'}"/>
</h:panelGroup>
}}}
!!!Captcha Component
In [JSF Ext] ist eine Captcha Component enthalten. Diese bringt ihre eigene Graphic-Resource mit, es werden also keine externen URLs angesprochen. Das Captcha ist also voll kompatibel zu HTTPS und AJAX. Kein dritter Provider kann ein Tracking der Site vornehmen.
!!Eigenschaften
Bei Captchas gibt es einige Unterschiede bezüglich des Lifecycle und der Validierung:
* __Default Lifecycle:__ Das Captcha wird in der Session abgelegt. Grundsätzlich führt ein Reload der Page zur Anzeige desselben Captchas.
* __Neues Captcha:__ Durch den Refresh-Knopf wird ein neues Captcha angezeigt. Die Klasse "Captcha" bzw. die Bean "captcha" kann das Captcha mit der Methode "reset" zurückgesetzt werden, sodass beim Rerendering ein neues Captcha angezeigt wird.
* __AJAX:__ Es spielt keine Rolle, ob das Captcha direkt im HTTP-Request geladen wird, oder ob es durch einen AJAX-Request nachgeladen wird. Im Gegensatz zu komplizierten IFrame und Javascript-Lösungen funktioniert <e:captcha> in den meisten Umgebungen.
* __Wiederholte Validierung:__ Die Eingabe kann ein- oder mehrfach positiv validiert werden. Das Captcha wird dabei nicht verändert, wenn es einmal erfolgreich validiert wurde. Der Benutzer kann damit andere Validierungsfehler beheben, ohne das Captcha ständig neu eingeben zu müssen.
* __Negative Validierung:__ Bei negativer Validierung, also Validation failed, wird ein neues Captcha generiert. Damit wird vermieden, dass der Anwender denselben Lesefehler wiederholt.
!!Beispiel
Das Captcha kann als Component in die Seite eingebaut werden:
{{{
<h:form id="form">
<e:captcha id="captcha"/>
<ext:message for=":form:captcha"/>
...
</h:form>
}}}
__Erklärung:__ Die Captcha Component rendert ein PNG-Image mit dem entsprechenden Text, sowie ein Eingabefeld, in dem der Text durch den Benutzer eingegeben wird. Die Component hat eine positive Validierung, wenn das Captcha korrekt ist, andernfalls schlägt die Validierung fehl und eine Faces Message wird eingefügt. Das Fehlschlagen der Validierung verhindert das Ausführen von Action Methoden, die an Command Buttons und ähnlichem hängen.
Um die Captcha Component zu verwenden, ist folgendes Maven Artifact in der pom.xml einzubinden:
{{{
<dependency>
<groupId>com.octo.captcha</groupId>
<artifactId>jcaptcha</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<artifactId>servlet-api</artifactId>
<groupId>javax.servlet</groupId>
</exclusion>
</exclusions>
<scope>provided</scope>
</dependency>
}}}
__Hinweis:__ Das Artifact hat die servlet-api im Scope "compile" eingebunden. Um das Deployen der servlet-api.jar zu vermeiden, ist die Exclusion erforderlich. Andernfalls kann es zu Problemen beim Deployment kommen.
!!!Behavior Tags
!!Characters Left
Bei Steuerelementen von Text-Areas oder Text-Input kann es von Vorteil sein, die Anzahl der möglichen Zeichen sehen zu können. Dazu fügt der Tag <e:charactersLeftBehavior> einen Zähler ein:
{{{
<h:inputTextarea id="comment" value="#{processDetails.comment}">
<e:charactersLeftBehavior event="keyup"/>
</h:inputTextarea>
}}}
__Erklärung:__ Die Anzahl möglicher Zeichen werden den Javax-Validation-Tags @Size und @Length oder dem LengthValidator entnommen. Die verbleibenden Zeichen werden dann im Text-Feld eingeblendet, die Eingabe wird auf die maximale Zeichenzahl begrenzt.
This page (revision-41) was last changed on 04-Sep-2014 13:44 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
24104 Aufrufe

referenziert von
JSF Ext
Jsf ext

© 2022 Intersult GmbH | Jobs | Kontakt | Presse | AGB | Impressum | Cookies | Datenschutz | Serverzeit 2024.05.20 09:53:01 GMT