JSF Ext Tags
Your trail: Docker

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 82 changed one line
!!
!!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
At line 90 changed one line
!!!AJAX-Tag
!!!AJAX Tag
At line 93 changed one line
!Sources
!!Sources
At line 113 changed one line
!Action Source
!!Action Source
At line 122 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 148 changed one line
!!!Attribute-Tag
!!!Attributes und Paramters
!!Attribute Tag
At line 165 changed one line
!Attribute-Behaviors
!!Attribute-Behaviors
At line 176 changed one line
!Zusammengesetzte Attribute
!!Zusammengesetzte Attribute
At line 189 changed one line
!Part-Attribute
!!Part Attribute
At line 206 changed one line
!Style-Attribute
!!Style Attribute
At line 219 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 224 changed one line
!!!New-Tag
!!New-Tag
At line 243 changed one line
!!!Set-Tag
!!Set-Tag
At line 279 changed one line
!!!Label
!!Label
At line 295 changed one line
!!!Move-Listener
Darüber hinaus können die Klassen requiredStyleClass und notRequiredStyleClass auch manuell festgelegt werden, indem diese als Attribut angegeben werden.
!!Move Listener
At line 313 changed one line
!!!Init-Tag
!!Init-Tag
At line 357 changed one line
!!!Otherwise-Tag
!!Otherwise-Tag
At line 376 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 453 changed one line
!!!For-Tag
!!For-Tag
At line 472 changed 2 lines
!!!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.
!!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 529 added 2 lines
Daher bietet [JSF Ext] einen Tag für das Rendern von vertikalen Text:
At line 476 changed 3 lines
<e:load viewId="/dialogs/someDialog.xhtml">
<e:method-param name="action" value="#{test.action}"/>
</e:load>
<e:vertical-text value="Hello World!" fontSize="16"/>
At line 481 changed one line
Damit können parameterisierte Dialoge erstellt werden, deren Action-Elemente bestimmte Methoden ausführen.
||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 483 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.
!!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 485 changed 2 lines
!!!Action Component
Manchmal kann es erforderlich sein, eine Method-Expression als Component zu übergeben oder mehrere Method-Expressions aufzurufen. Dafür kann der Tag <e:action> verwendet werden:
!!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 488 changed 8 lines
{{{
<h:commandButton value="Invoke Actions">
<f:ajax/>
<e:action listener="#{bean.action1}"/>
<e:action listener="#{bean.action2}"/>
<e:action listener="#{bean.action3}"/>
</h:commandButton>
}}}
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 497 changed 2 lines
!!!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.
!!!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 500 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.
Die alte Implementierung über Render-Attribute führt zu folgenden Verbesserungswünschen:
At line 502 changed one line
Dazu ist folgende Dependency zum Projekt hinzuzufügen:
* __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.
At line 559 added 2 lines
Die Lösung sind Events und der Render-Tag. Typischer Weise werden Events durch den Code ausgelöst, wie etwa beim Login:
At line 505 changed 5 lines
<dependency>
<groupId>org.atmosphere</groupId>
<artifactId>atmosphere-runtime</artifactId>
<version>2.1.0-beta1</version>
</dependency>
Event.instance().raise(EVENT_LOGIN, authentication.getPrincipal());
At line 512 changed 2 lines
!!Push-Tag
Der Push-Tag ist die einfachste Art, AJAX-Push zu implementieren. Der Tag <e:push> stellt eine transparente Verbindung zu einem Push-Channel her. Der Inhalt des Tags wird auf alle Clients verteilt, die mit dem gleichen Channel verbunden sind:
Dadurch werden Bereiche neu gerendered:
At line 516 changed 12 lines
<h:form id="form">
<h:commandButton value="Senden" action="#{pushTest.action}">
<f:ajax render=":test:value"/>
</h:commandButton>
</h:form>
<e:push id="test" direct="true">
<h:panelGrid id="panel" columns="2">
<h:outputText id="text" value="Test"/>
<h:outputText id="value" value="#{pushTest.count}"/>
</h:panelGrid>
</e:push>
<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 530 changed one line
__Erklärung:__ Der Tag ":test:value" wird durch eine einfache AJAX-Render-Anweisung auf allen verbundenen Clients neu gerendert.
__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 532 changed 2 lines
!Direct- und AJAX-Mode
Der Push-Tag kann in zwei unterschiedlichen Modi betrieben werden: Direct und AJAX:
__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 535 changed 6 lines
||Eigenschaft||Direct Mode||AJAX Mode
||Rendering|Inhalt wird nur bei dem Client gerendert, der den Event ausgelöst hat|Inhalt wird für jeden Client gerendert
||Effizienz|Effizienter Modus, da das HTML-Update direkt an alle Clients geschickt werden kann|Rendering wird für jeden Client getrennt gerendert
||Inhalt|Inhalt ist für jeden Client identisch|Inhalt kann für jeden Client individualisiert werden
||Daten|Anzeige von Daten die für mindestens eine Gruppe bestimmt oder öffentlich ist|Anzeige privater Daten möglich
||Auslöser|Auslöser ist ein Faces-Event|Auslöser kann ein Faces-Event, Timer oder beliebiger anderer Event sein
!!!Action Support
!!Action Tag
Manchmal kann es erforderlich sein, eine Method-Expression als Component zu übergeben oder mehrere Method-Expressions aufzurufen. Dafür kann der Tag <e:action> verwendet werden:
At line 542 removed 13 lines
!Rendering
Die beim Render-Attribut angegebenen Ids werden einzeln gerendert und nur der relevante Inhalt zum Client übertragen. Auch wenn sich innerhalb des Push-Tag große Mengen an Tags befinden, wird nur die relevante Änderung übertragen, sofern die Render-Anweisungen entsprechend ausgelegt sind.
Damit ist es beispielsweise möglich, eine Tabelle zu erzeugen und einzelne Zellen per Push upzudaten.
!Channel
Wird der Channel-Attribut nicht angegeben, wird die Client-Id der Component als Channel benutzt.
__Warnung:__ Channel-Name und Push-Tag sollte für alle Clients übereinstimmen, damit die Inhalte übereinstimmen. Andernfalls kommt es zu sogenannten Cross-Talking - der Inhalt des Push-Tags ändert sich.
!!Socket-Tag
Mit dem Socket-Tag ist eine fortgeschrittenere Integration von AJAX-Push in die Applikation möglich. Dazu wird einfach ein sogenannter Socket in die XHTML-Seite gesetzt:
At line 556 changed 3 lines
<e:socket channel="/test">
<f:ajax render=":push-form:chat"/>
</e:socket>
<h:commandButton value="Invoke Actions">
<f:ajax/>
<e:action listener="#{bean.action1}"/>
<e:action listener="#{bean.action2}"/>
<e:action listener="#{bean.action3}"/>
</h:commandButton>
At line 561 changed one line
Auf der Java-Seite wird der Socket dann so angesprochen:
!!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 599 added 2 lines
Der Workaround besteht im Wrappen des Tags <e:actionContext> um die eigentliche Action-Source:
At line 564 changed one line
PushContext.instance().push("/test");
<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 567 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.
__Erklärung:__ Bei der Primefaces Tree-Table wurde offenbar vergessen der Component-Push
At line 569 changed one line
Die Socket-Component unterstützt folgende Attribute und Behaviors:
!!!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 571 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.
!!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.
At line 578 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:
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.
At line 623 added 2 lines
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 582 changed one line
PushContext.instance().push("/test");
<ext:busyPointer/>
At line 585 changed 2 lines
!!Push-Parameter
Optional kann der Aufruf auch mit einem Parameter erfolgen, der wird dann JSON-Serialisiert und an den Client übertragen:
Optional kann das Attribut cursor angeben werde, das per default auf "wait" gesetzt ist.
At line 588 changed 3 lines
{{{
PushContext.instance().push("/test", parameter);
}}}
!!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 one line
Auf der Client-Seite kann der Parameter dann wie folgt entgegen genommen werden:
Eine Lösung ist der Tag <ext:mouse-visibility>:
At line 595 changed one line
<e:socket channel="/test" onmessage="alert(response.responseBody);">
<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 598 changed 2 lines
!!Load Balancer und Reverse Proxy
Wird ein Load-Balancer verwendet, sind die Web-Sockets zu beachten. Bei Apache werden folgende Proxy-Einträge vor der eigentlichen Applikation gebraucht:
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.
At line 652 added 3 lines
!!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 602 changed 2 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>
<ext:onscroll>
<e:ajax action="#{dashboard.more}" render=":dashboard-form:transaction-list:list"/>
</ext:onscroll>
At line 606 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.
__Erklärung:__ Der Tag führt das Behavior <e:ajax/> aus, sobald ans untere Ende der Page gescrollt wird.
At line 608 changed one line
!!!Resource-Tag
!!!Resource Link
At line 629 changed one line
__Hinweis:__ Wie der normale <h:outputLink> unterstützt <h:resourceLink> ebenfalls Parameter vom Typ <f:param> (und abgeleitete Parameter wie <f:method-param> und <f:new>).
__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]
At line 631 changed 2 lines
!!!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.
!!!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.
At line 634 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.
!!Einfache Message
[JSF Ext] stellt daher selbst rendernde Faces-Messages zur Verfügung als Tag <ext:message>.
At line 637 changed one line
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.
!!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.
At line 639 changed one line
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:
Der Severity-Tag ist eine Composite Component mit folgender Implementierung:
At line 642 changed one line
<ext:busyPointer/>
<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>
At line 645 changed one line
Optional kann das Attribut cursor angeben werde, das per default auf "wait" gesetzt ist.
!!!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.
At line 647 changed 2 lines
!!!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.
!!Eigenschaften
Bei Captchas gibt es einige Unterschiede bezüglich des Lifecycle und der Validierung:
At line 650 changed one line
Eine Lösung ist der Tag <ext:mouse-visibility>:
* __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.
At line 721 added 3 lines
!!Beispiel
Das Captcha kann als Component in die Seite eingebaut werden:
At line 653 changed 11 lines
<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>
<h:form id="form">
<e:captcha id="captcha"/>
<ext:message for=":form:captcha"/>
...
</h:form>
At line 666 changed one line
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.
__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
24113 Aufrufe

referenziert von
JSF Ext
Jsf ext

© 2022 Intersult GmbH | Jobs | Kontakt | Presse | AGB | Impressum | Cookies | Datenschutz | Serverzeit 2024.05.20 11:52:05 GMT