This page (revision-6) was last changed on 22-Nov-2017 10:56 by Dieter Käppel

This page was created on 17-Mar-2017 11:26 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
6 22-Nov-2017 10:56 19 KB Dieter Käppel to previous
5 22-Nov-2017 10:56 19 KB Dieter Käppel to previous | to last
4 26-Mar-2017 10:37 18 KB Dieter Käppel to previous | to last
3 26-Mar-2017 10:32 17 KB Dieter Käppel to previous | to last
2 26-Mar-2017 10:16 13 KB Dieter Käppel to previous | to last
1 17-Mar-2017 11:26 7 KB Dieter Käppel to last

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 3 removed 5 lines
__Achtung:__ [JSF-JQuery 2] wurde durch [JQueryWidget2] abgelöst. Verwenden Sie jetzt [JQueryWidget2], um noch kompatibler und effizienter [JQuery] mit [JSF] zu kombinieren.
!!!Inhalt
[{TableOfContents title='Page contents' numbered='true'}]
At line 78 changed 111 lines
!!Options
In der Regel bedarf es einiger Optionen, mit denen das Widget gesteuert werden kann. Dazu gibt es mehrere Mechanismen, mit der Tag-Attribute, Attribut-Tags oder Behaviors übergeben werden können.
!Default Options
Eine Reihe von Options sind bereits im JQueryWidget selbst implementiert, weil diese häufig benötigt werden:
||Option||Typ||Wert||Erklärung
|url|custom|getUrl()|Der Kanal über den das Widget mit dem Server kommuniziert. Dieser sollte nur geändert werden, wenn man einen eigenen Resource-Handler implementieren möchte. Dafür sollte man einen guten Grund haben.
|dataType|property|script|Legt den Mime-Type fest, mit dem das Widget mit dem Server kommuniziert. Mögliche Werte sind script, json, xml oder text. Die Funktionalität der Widget-Funktionen sind allerdings nur im Default gewährleistet. Andernfalls sind entsprechende Funktionen zu überschreiben.
Weitere Optionen werden nicht an das Widget übergeben, aber direkt an den vom Java-Code generierten XHTML-Code:
||Option||Typ||Wert||Erklärung
|style|property|empty|Mit diesem Tag-Attribut oder Property können Style-Informationen an das Top-Level DIV-Element des Widgets übergeben werden.
|styleClass|property|getWidgetStyleClass()|Dieses Attribut oder Property übergibt Style-Klassen an das Widget. Default ist, die Methode getWidgetStyleClass() aufzurufen, deren Default-Wert wiederum ist j-<lower widget name>, also der Class-Name des Widget in Kleinschrift.
!Property Options
Dazu kann die Methode getOptions überschrieben werden:
{{{
@Override
public String getOptions(Object... properties) {
return super.getOptions("customOption");
}
}}}
Alle hier angegebenen Properties werden als Java-Properties der Java-Component an das Javascript-Widget übergeben. Die Implementierung auf der Java-Seite erfolgt im typischen JSF-Style:
{{{
public String getCustomOption() {
return (String)getStateHelper().eval("customOption");
}
public void setCustomOption(String customOption) {
getStateHelper().put("customOption", customOption);
}
}}}
Beispiel:
{{{
<j:test customOption="some option"/>
}}}
__Hinweis:__ Jede Option kann ebenfalls eine EL-Expression enthalten.
!Behavior Options
Alle dem Tag untergeordneten Behaviors, also beispielsweise <p:ajax> oder <e:behavior> werden dem Javascript-Widget in Form von Javascript-Funktionen übergeben:
{{{
<j:autocomplete id="autocomplete" value="#{jqueryController.value}" complete="#{jqueryController.complete}">
<p:ajax event="change" listener="#{jqueryController.action}"/>
</j:autocomplete>
}}}
__Erklärung:__ Das Javascript-Widget implementiert den Event "change". Dieser kann dann auf der XHTML-Seite durch einen entsprechenden Client-Behavior Tag verarbeitet werden, wie das von Tags, wie <h:inputText> gewohnt ist.
!Parameter Options
Eine weitere Möglichkeit zur Übergabe von Optionen ist die Param-Tag-Familie mit den Implementierungen <f:param>, <j:param>, <j:function>:
* __<f:param>:__ Der standardmäßige Parameter-Tag übergibt das Name-Value-Paar 1:1 via JSON an das Widget. Der Value darf dabei eine EL Value-Expression darstellen und ein komplexes Objekt enthalten, das natürlich JSON serialisierbar sein muss. Dabei können Jackson-Annotationen verwendet werden, um die Serialisierung zu steuern. Insbesondere darf auch das Interface JsonSerializable implementiert werden und die von Jackson mitgelieferte Variante RawValue genutzt werden.
* __<j:function>:__ Dieser Parameter übergibt eine Javascript-Funktion. Da <f:param> die Werte immer zu Strings macht, kann man mit <f:param> keine Javascript-Parameter übergeben, man braucht daher einen anderen Tag, wie eben <j:function>. Dieser Tag unterstützt das Attribut arguments, um die Komma seperierte der Javascript Argumente zu definieren. Der Javascript-Code kann sich sowohl im Value-Attribut (wenig Code) oder im Text-Body des Tags (viel Code) befinden. Für größeren Code sollte man ohnehin eine Javascript-Datei schreiben und aus dem Tag nur referenzieren.
* __<j:param>:__ Mit diesem Tag kann der Value frei übergeben werden. Der Tag sollte nur als allerletzte Lösung verwendet werden, weil dadurch die Gefahr von ungültigem JSON-Code entsteht, der zu einem Javascript-Fehler führt und die Ausführung der Web-Seite verhindert.
Beispiel:
{{{
<j:autocomplete id="autocomplete" value="#{jqueryController.value}" complete="#{jqueryController.complete}">
<p:inputText id="input" autocomplete="off"/>
<j:function name="cellRenderer", arguments="$row, key, value">
if (key == "styleClass") {
$row.addClass(value);
} else {
var $cell = $("<td/>");
$cell.attr("title", value);
$cell.html(value);
if (key == "label") {
$cell.css("background-color", "black");
$cell.css("color", "yellow");
}
$row.append($cell);
}
</j:function>
</j:autocomplete>
}}}
!Custom Options
Die einfachste Möglichkeit um dynamisch berechnete Optionen hinzuzufügen ist es, ein Property-Option zu definieren und den Getter zu implementieren. Aber es gibt noch eine weitere Methode, mit der man Options hinzufügen kann:
{{{
public void addWidgetOptions(Map<String, Object> options) {
options.put("name", "value");
}
}}}
!!!Styling
Wie beim Property styleClass bereits beschrieben, erhält das Top-Level-DIV des Widgets die Style-Class j-<lower widget name>. Wenn die Widget-Klasse also Autocomplete heißt, bekommt sie die Style-Class j-autocomplete. Damit dürfte ein Großteil der Styling-Regeln im CSS behandelbar sein.
Beispiel:
{{{
.j-autocomplete > .j-autocomplete-panel {
display: none;
z-index: 1;
max-height: 300px;
overflow-x: hidden;
overflow-y: auto;
white-space: nowrap;
}
}}}
!!!Server Requests
!!!JQueryResourceHandler