Aktualisierungen November, 2009 Kommentarverlauf ein-/ausschalten | Tastaturkürzel

  • Andreas Höhmann 16:35 am Monday, 16. November 2009 Permalink |
    Tags: , , , ,   

    Richfaces modal panel default formular action 

    Each input dialog should have a default action for good useability.

    If the user hit ‚Enter‘ then the default action should execute.

    Here is my example of a richfaces modal edit dialog for such a requirement …

    The dialog have input fields and 3 actions:

    • save – is the default action if the user hit ‚Enter‚ anywhere in the formular
    • cancel – is the default action if the user hit ‚Esc‚ anywhere in the formular
    • reset
    <modalPanel id="edit_dialog">
      <a4j:form id="edit_form" ajaxSubmit="true">
        <!-- some fields ... -->
        <outputLabel value="What's your title:" for="title"/>
        <inputText  id="title" value="#{bean.title}"/>
        <outputLabel value="What's your name:" for="name"/>
        <inputText  id="name" value="#{bean.name}"/>
        <!-- the actions ... -->
        <a4j:commandButton id="save" value="Save" action="#{bean.save}" type="submit"
             oncomplete="if(#{facesContext.maximumSeverity==null}) Richfaces.hideModalPanel('edit_dialog')"/>
             <!-- if no error then close the edit-dialog ... 
                    is not necessary if you don't use dialogs -->
         <a4j:commandButton id="reset" value="Reset" action="#{bean.reset}"
              limitToList="true" reRender="edit_form" ajaxSingle="true" type="reset"/>
         <a4j:commandButton id="cancel" value="Cancel" action="#{bean.cancel}" ajaxSingle="true"
         <!-- the default actions for the formular 'onEnter' and 'onEsc' ... -->
         <rich:hotKey key="return" selector="#edit_form"
             handler="${rich:element('edit_form:save')}.click();event.stopPropagation();event.preventDefault(); return false;"
         <rich:hotKey key="esc" selector="#edit_form"
             handler="${rich:element('edit_form:cancel')}.click();event.stopPropagation();event.preventDefault(); return false;"

    It’s important to define ajaxSubmit=“true“ for the form! This avoid „none ajax submit of html formulars“. I will explain this in a later blog 🙂

    With rich:hotKey I bind 2 key events to the edit formular:

    • on ‚enter‘ – the handler click the save button
    • on ‚esc‘ – the handler click the cancel button

    Try it 😀

    • hicham7412 23:20 am Mittwoch, 23. Juni 2010 Permalink | Zum Antworten anmelden

      Hi Andreas,

      interesting post, I am just wondering why you always put return false; in the handler of the hotKey.

      • Andreas Höhmann 8:40 am Donnerstag, 24. Juni 2010 Permalink | Zum Antworten anmelden

        I do this because it would stop the event propagation … Do you think this is not necessary?

        event.stopPropagation();event.preventDefault();return false;

    • ikren05 3:34 am Montag, 23. August 2010 Permalink | Zum Antworten anmelden

      i’ve just done the same.. clicking enter saves the changes. clicking esc does nothing.. anyone, please help.. thank you in advance 😀

    • dominic89 16:14 am Donnerstag, 26. August 2010 Permalink | Zum Antworten anmelden


      I tried a little diffrent way to close the ModalPanel. I have a Textinputfield with attribute required =“true“.
      If I press the save button the ModalPanel is empty (no Text,Fields and Buttons are shown) but it doesn’t close.

      Maybe you have an idea why the panel doesn’t close

      thank you in advance

    • rajendraj 7:44 am Dienstag, 31. August 2010 Permalink | Zum Antworten anmelden

      Hai Andreas,
      I am new to rich faces; I am using calendar component i can able select the date from the calendar component, now i am trying to enter date into the calendar component for that i have used enable manual inout = ‚true‘ and i am able to enter date into the calendar component.I have kept the datepattern =’dd-MMM-yyyy‘ so accordingly i am able to enter date. Now my question or functionality is:

      Q. I need to enter date manually into the calendar component like:31082010
      after an event like onblur or onenterkeypress it should change the pattern into user defined format like(31-Aug-2010).
      How to achieve in the calendar component, Is it same like text field entry??
      Please explain me how to do that???

    • rajendraj 7:46 am Dienstag, 31. August 2010 Permalink | Zum Antworten anmelden

      I forgot to tell; I have asked this question in rich faces forums also, please tell how to achieve the above functionality?? Thanks in advance Andreas

  • Andreas Höhmann 15:57 am Monday, 16. November 2009 Permalink |
    Tags: focus, , , , rich,   

    Richfaces modal panel autofocus first input element 

    With jQuery it’s easy to focus the first visible input element (textfield, textarea or selectbox) for a rich:modalPanel:

    <rich:modalPanel onshow="autofocus('dialog_content')">
      <h:panelGrid id="dialog_content" columns="1" width="100%" cellpadding="0" cellspacing="0">
         <a4j:form ajaxSubmit="true">
           <h:outputLabel value="What's your name:" for="name"/>
           <h:inputText  id="name" value="#{bean.name}"/>
           <a4j:commandButton id="save" value="Save my name" action="save"/>
    function autofocus(containerId) {
      var element = jQuery(":input:not(:button):visible:enabled:first", '#'+containerId);
      if (element != null) {
  • Andreas Höhmann 15:50 am Friday, 6. November 2009 Permalink |
    Tags: backspace, disable, , javascript, , ,   

    Disable backspace key in a Richfaces application 

    If you want disable the Backspace key in your JSF Richfaces application put this in your view:

    <rich:hotKey key="backspace" handler="return false;" disableInInput="true"/>

    This will register a jQuery Hotkey handler for the document. The handler is not reqistered for input elements because in input fields you need the backspace ;-). Tested for FF3 and IE6.

    Then I found out that the following snippet doesn’t work:

    <rich:hotKey key="backspace"
                 handler="alert('Backspace is disabled'); return false;" />

    The Browser open the alert box and go to the previous page (in background?!). But there is a fix for that:

    <rich:hotKey key="backspace"
                 handler="alert('Backspace is disabled'); event.stopPropagation(); event.preventDefault(); return false;" />

    The event variable is available in the handler function (see org.richfaces.renderkit.html.HotKeyRenderer method doEncodeEnd).

  • Andreas Höhmann 13:42 am Thursday, 10. September 2009 Permalink |
    Tags: collapse, , expand, rich faces,   

    Customized Richfaces Tree 

    Yesterday I had to customize the Richfaces tree component, because my client wants a special layout. My solution is a little bit strange. I share it here for someone which is in the same situation 😉 Here is the story …

    Per default the rich:tree looks like a standard tree browser (i.e. explorer, eclipse, whatever):


    But I want this look:


    You see that the expand/collapse icon (rich_tree_expand) is on the same level with the node-icon (rich_tree_leaf). That’s very hard to fix this with CSS (it’s possible but i prefer my strange solution ;)). The Richfaces documentation describes which parts of a tree could be customize.

    We have:

    • rich-tree-node-handle and rich-tree-node-handleicon – a td which contains a link and a image to expand/collapse the node (only possible for a node not a leaf)
    • rich-tree-node-icon – is a td which contains the image for a node (a node with children)
    • rich-tree-node-icon-leaf – is a td which contains the image for a leaf (a node without children)

    I decide to move the expand/collapse icon from the handle-td to the icon-td and „simulate“ the user-click with Javascript:


    Listing 1 tree.xhtml:

    <rich:tree id="tree"
        <f:facet name="iconCollapsed">
           <!-- no image for collapsed --> 
           <rich:spacer width="0"  height="0" style="border: none;"/>
        <f:facet name="iconExpanded">
           <!-- no image for expanded --> 
           <rich:spacer width="0"  height="0" style="border: none;"/>
        <f:facet name="icon">
           <!--  use normal node icon to toggle expand/collapse -->
              <h:graphicImage value="#{item.isLeaf ? '/images/leaf.gif' : '/images/collapsed.gif'}" 
              <h:graphicImage value="#{item.isLeaf ? '/images/leaf.gif' : '/images/expanded.gif'}" 
        <f:facet name="iconLeaf">
           <h:graphicImage value="/images/leaf.gif"/> 
        <rich:recursiveTreeNodesAdaptor roots="#{treeBean.roots}" var="item" nodes="#{item.children}">
              <h:outputText value="#{item.name}"/>

    Listing 2 tree.js:

    function myToggleTreeNode(element) {
      var elem = jQuery(element);
      // img -> span -> td
      var parent = elem.parent().parent();
      var elementId = parent.attr("id");
      // i.e. j_id31:tree:j__id39:18::j_id40:icon -> the td arround the icon-image
      var index = elementId.lastIndexOf(":icon");
      var treeNodeId = elementId.substring(0, index);
      // i.e. j_id31:tree:j__id39:18::j_id40:handle -> the td arround the original expand/collapse-image
      var handleId = treeNodeId+':handle';
      // pure jQuery not working here
      var expandElement = jQuery($(handleId));

    Listing 3 tree.css:

    .rich-tree-node-handleicon {
      display: none;
  • Andreas Höhmann 9:55 am Monday, 7. September 2009 Permalink |
    Tags: , , JSF 2, , ViewExpiredException   

    ViewExpiredException in JSF 1 and 2 

    Ed Burns beschreibt in seinem Blog wie man in JSF 2 selbst eine ViewExpiredException’s behandeln kann.

    Momentan (JSF < 2) kann die Standard-Fehlerbehandlung natürlich auch angepasst werden, z.B. durch Festlegung einer bestimmten Location pro Exception-Typ:

    <?xml version="1.0" encoding="UTF-8"?>
    <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

    In der von Ed vorgestellten Lösung wird ein eigener ViewExpiredExceptionHandler registriert, welcher den ursprünglichen Handler kapselt. In der dort überschriebenen void handle() wir eine ViewExpiredException mit einem Redirect (via Navigation-Handler) auf eine Fehlerseite beantwortet. In der Fehlerseite können Variable, die im Handler gesetzt wurden, für eine sinnvolle Fehlerbeschreibung verwendet werden.

    Beim Einsatz von Richfaces kann man diese Art von Fehler auch auf der Clientseite behandeln, beschrieben wird dies im Detail hier. Das Ganze ist mit zwei Erweiterungen machbar:

    1. die Funktion für den Client aktivieren


    2. den Javascript-Code für die Behandlung zur Verfügung stellen:

    if (typeof(A4J) !== 'undefined' && typeof(A4J.AJAX) !== 'undefined'){
       // richfaces is available
       A4J.AJAX.onExpired = function(loc,expiredMsg) {
          var confirmMsg = 'Session expired.\n\nReload?';
          if (confirm(confirmMsg)) {
          // return false to inform "link-commands", that the user doesn't want to reload the page
          return false;
  • Andreas Höhmann 17:59 am Wednesday, 22. July 2009 Permalink |
    Tags: Appear, Effect, Fadein, Fadeout, , , Scriptaculous   

    Fadein and Fadeout a Richfaces ModalPanel 

    Today i explain you a cool combination for rich:modalPanel and rich:effect.

    In the richfaces forum i found a article about a modalpanel with scriptaculous-effects („fade-in a modalpanel“). The answer was a link to the official richfaces demo-application (photoalbum). There we can find a login-dialog (svn source) with a „appear-effect“:

    <rich:modalPanel id="loginPanel"
    onshow="applyModalPanelEffect('loginPanel', appearFunc,{delay: 0.5, afterFinish: function(){$('loginPanelForm:username').focus();}})"
    width="400" height="150" autosized="true">
    <f:facet name="header">#{messages['login.login']}</f:facet>
    <f:facet name="controls">
    <h:panelGroup id="loginPanelHideControl">
    <h:graphicImage value="/img/modal/close.png" style="cursor:pointer"
    id="loginPanelhidelink" onclick="#{rich:component('loginPanel')}.hide();"/>
    <rich:effect type="Appear" name="appearFunc"/>

    The javascript method applyModalPanelEffect can be found in the photoalbum.js (svn source):

    function applyModalPanelEffect(panelId, effectFunc, params) {
     if (panelId && effectFunc) {
     var modalPanel = $(panelId);
     if (modalPanel && modalPanel.component) {
     var component = modalPanel.component;
     var div = component.getSizedElement();
    effectFunc.call(this, Object.extend({targetId: div.id}, params || {}));}}

    With this the rich:modalPanel will not shown immediately … it appears 😉 This was the „fade-in part“.

    I improved the code for the „fade-out part“, first the dialog:

    <!-- first the effects -->
    <rich:effect type="Appear" name="appearDialog"/>
     <rich:effect type="Fade" name="disappearDialog"/>
    <!-- to keep the dialog-code clean -->
    <c:set var="closeDialog" value="hideModalPanelWithEffect('myDialog',disappearDialog,{delay:0.1,duration:0.5})"/>
    <rich:modalPanel id="myDialog"
     width="610" height="350" minHeight="350" autosized="true" shadowDepth="0">
    <f:facet name="controls">
    <h:graphicImage value="/img/modal/close.png" style="cursor:pointer" onclick="#{closeDialog}"/>

    and the javascript:

    function applyModalPanelEffect(panelId, effectFunc, params, hide) {
     if (panelId && effectFunc) {
     var modalPanel = $(panelId);
     if (modalPanel && modalPanel.component) {
     var component = modalPanel.component;
     var div = component.getSizedElement();
     if (hide) {
     effectFunc.call(this, Object.extend( {targetId : div.id}, params || {}));}}
    function showModalPanelWithEffect(panelId, showEffect, params) {
     applyModalPanelEffect(panelId, showEffect, params, true);
    function hideModalPanelWithEffect(panelId, hideEffect, params) {
     var _params = params;
    _params['afterFinish'] = function(){Richfaces.hideModalPanel(panelId)};
     applyModalPanelEffect(panelId, hideEffect, params, false);

    Now the dialog call showModalPanelWithEffect to fade-in and hideModalPanelWithEffect to fade-out.

    Try it 😀

  • Andreas Höhmann 17:13 am Monday, 22. June 2009 Permalink |
    Tags: Input, , , Reset,   

    Clear JSF Input Components 

    Beim Implementieren einer einfachen CRUD Anwendung mit Hilfe von Richfaces Datatable und ModalPanel bin ich über ein „Problem“ mit validierten (leeren) Eingabefeldern gestolpert.

    Das Problem ist eigentlich kein richtiges Problem, sondern das Standardverhalten von JSF 🙂 Unschön wird es wenn man einen rich:modalPanel als Edit-Dialog einsetzt und diesen wiederverwendet.

    Der grobe Aufbau:

    • eine DataTable zeigt eine Liste von Entities (z.B. mit Hilfe eine DAOs geladen)
    • jedes Entity hat eine eindeutige ID (z.B. PrimaryKey aus JPA)
    • pro Tabellenzeile gibt es einen „Edit“-CommandLink der eine rich:modalPanel für das Editieren eines Entity öffnet
    • vor jedem Edit muss die gewünschte Entity in einen CrudManager (Session-Scoped Bean) gelangen, aus der sich der Edit-Dialog mit Daten versorgen kann und mit dessen Hilfe die eigentliche Edit-Aktion durchgeführt wird

    Nun sollen bestimmte Eingabefelder im Edit-Dialog validiert werden (z.B. mit einer @NotEmpty Annotation an den ensprechenden Properties der Entitiy-Klasse). Wenn man nun den Dialog für eine Entity mir der ID ‚1‘ öffnet und eine Validierungsfehler auslöst, z.B. durch das Abschicken mit leeren Eingabefeldern, wird dieser Fehler ausgegeben … soweit so gut. Der Dialog kann dann geschlossen werden. Soll nun Entity mit der ID ‚2‘ mit dem gleichen Dialog editiert werden, sind die Eingabefelder immer noch leer und nicht wie gewünscht mit den Werten aus Entity-2 gefüllt. Warum?!

    Nach einer kurzen Googlesuche landete ich auf der Seite http://wiki.apache.org/myfaces/ClearInputComponents die den Effekt beschreibt. Der Grund für das Verhalten ist die Zwischenspeicherung von „SubmitedValues“ in den jeweiligen UIComponents (z.B. h:inputText). Die werden den eigentlichen Modeldaten vorgezogen.

    Will man nun einen immer aktuellen Edit-Dialog haben, gibt es verschiedene Möglichkeiten (siehe MyFaces). Ich habe mich für die „radikal einfache“ Lösung entschieden … lösche alle Elemente innerhalb des Edit-Dialogs und lasse sie immer neu erzeugen.

    Die Entity-Liste besteht aus einer rich:dataTable, pro Zeile ein a4j:commandButton:

    <rich:dataTable value="#{tableManager.model}" var="dataItem">
    <!-- Edit-Command Column -->
    <rich:column sortable="false">
    <a4j:commandButton ajaxSingle="true" limitToList="true"
     <f:attribute name="onEditClearTarget" value="foobar_editPanel"/>
     <f:setPropertyActionListener value="#{dataItem}" target="#{crudManager.currentEntity}" />
    <!-- more Columns ... -->

    Der tableManager liefert die Entity-Daten, also eine Liste von Entity-Beans, jede Bean hat eine eindeutige ID. Der crudManager enthält stellt die gesamte CRUD Funktionalität zur Verfügung. Für eine Edit muss er mit einer Entity „initialisiert“ werden, dies geschieht via f:setPropertyActionListener. Das reRender bewirkt, dass der Edit-Dialog aktuallisiert wird.

    Der Edit-Dialog wird mit Hilfe von rich:modalPanel erzeugt (foobar_editPanel) und enthält eine Reihe von h:inputText Elementen. Diese sind wiederum an den crudManager gebunden.

    Der Code für das Zurücksetzen der Inputelemente im Edit-Dialog ist ebenfalls im crudManager verborgen und sieht folgendermaßen aus:

    public abstract class AbstractCrudManager {
    public static final String ONEDIT_ATTRIBUTE_CLEARTARGET = "onEditClearTarget"; //$NON-NLS-1$
    <li>Event-handler will be triggered on <tt>edit</tt>. This method is used as a</li>
    <li>{@link ActionListener} and will be called before a <tt>edit-view</tt> is</li>
    <li>shown. So here we can do some "initializations" for the edit-view, i.e.</li>
    <li>reset input-fields.</li>
    <li>This base implementation will call {@link #clearEditTarget(UIComponent)}.</li>
    <li>@param aEvent</li>
     *          is never <code>null</code>
    public void onEdit(final ActionEvent aEvent) {
    <li>This method handle a edit-form-clear. Per default the command-button which delegates to the</li>
    <li>edit-view could have a attribute {@link #ONEDIT_ATTRIBUTE_CLEARTARGET}.</li>
    <li>@param theSourceComponent</li>
     *          is never <code>null</code>
     protected void clearEditTarget(final UIComponent theSourceComponent) {
     final String onEditTarget = (String) theSourceComponent.getAttributes().get(ONEDIT_ATTRIBUTE_CLEARTARGET);
     if (onEditTarget == null) {
     final UIComponent editTarget = FacesContext.getCurrentInstance().getViewRoot().findComponent(onEditTarget);
     if (editTarget == null) {

    Damit ist auch klar was das <f:attribute name=“onEditClearTarget“ value=“#{id}_editPanel“/> bewirkt … es definiert die UI-Komponente die vor dem Öffnen des Dialogs zurückgesetzt werden soll.

    Damit wird bei jedem Klick auf „Edit“ ein Ajax-Request zum Server geschickt, dort wird die aktuelle Entity in den crudManager hinterlegt, es wird onEdit aufgerufen und damit der Inhalt des Edit-Dialogs gelöscht. JSF sorgt dann beim RenderResponse wieder dafür, dass alle UI Componenten korrekt erzeugt werden. Da dann alle Eingabeelement noch vollkommen „neu“ sind, zeigen diese auch die Werte aus dem Modell an.

  • Andreas Höhmann 12:30 am Monday, 27. April 2009 Permalink |
    Tags: , Example, , , Realworld,   

    Realworld JSF Application Story 

    Vielleicht hatte ich es in einem früheren Posting schonmal erwähnt, ich arbeite momentan für einen großen dt. Firma an einem Web 2.0 Projekt und das ist jetzt fertig 😀

    Ich konnte dabei all die wunderbaren „neuen“ Technologien einsetzen, u.a. JSF und damit eine funktionsfähige (also den Anforderungen des Kunden voll entsprechende) und zugleich performante „Web 2.0“ Applikation bauen.

    Die Applikation nimmt sich dem Thema „Sicherheitstechnik“ (für die Auskenner: ISO 13849-1 und IEC 62061) an.

    Mal kurz zu den verwendeten „Technologien/Frameworks/Tools/Ideen“:

    • Daten ziehen wir aus einer SAP Knowledgebase und aus einer Datenbank via OpenJPA
    • Services/Manager sind „normale“ Javaklassen (Stichwort Design-Pattern),
      als Kleber verwenden wir Spring (Stichwort Dependency Injection)
    • UI mit JBoss Richfaces (Stichwort Ajax), JSF + Facelets (Stichwort Xhtml-Template), jQuery, CSS, etc.
    • Buildsystem, Projektseiten mit Maven2
    • Continues Integration via TeamCity und Maven2
    • Tests hauptsächlich mit TestNG aber teilweise auch mit JUnit
    • Laden/Speichern von Benutzerdaten via XStream (FileupLoad via Tomahawk), das alles noch Versionskompatibel, d.h. selbsgestrickte XML-Transformationskette für DomainModell-Updates
    • PDF Reportgenerierung mit iText
    • Anbindung an ein „Single Sign On“ System via Spring Security, Webservices

    Im Rückblick kann ich sagen, dass eigentlich alles ohne größere Probleme miteinander funktioniert hat
    … so soll es sein 😀

  • Andreas Höhmann 18:04 am Wednesday, 4. March 2009 Permalink |

    Show Richfaces Version 

    Richfaces provide his version in the el-variable a4j.

    So put a #{a4j} in a facelets-template and you will see a version-string like this

    Jboss Richfaces by richfaces.org, version v.3.3.0.GA SVN $Revision: 12244 $ $Date: 2009-01-13 05:40:53 +0200 $

  • Andreas Höhmann 23:12 am Tuesday, 9. September 2008 Permalink |
    Tags: Adapter, Node, , Select,   

    Richfaces internal Tree Node Selection Howto 

    Waffel beschreibt in seinem neuesten Blogbeitrag wie man den Richfaces Tree auch aus dem System heraus ansprechen kann um eine bestimmte Node zu selektieren und sichtbar zu machen. So auf anhieb findet sich bisher keine vernünftige Dokumentation zu dem Thema.

    Er kombiniert in seinem Beispiel den Tree mit einem TreeNodeAdapter (um das lästige Erstellen der Nodeklassen zu überspringen) und benutzt schließlich einen TreeWalker um die gewünschte Node zu finden und aufzuklappen.

    Vielleicht wird in einer der nächsten RF-Versionen das Handling mit dem Baum ja noch einfacher. Aus Benutzersicht (UI) läßt der Baum ja kaum noch Wünsche offen. Serverseitig sieht es da schon etwas dünner aus. Aber wenn man sich einmal bissl tiefer reingewühlt hat, wird auch da manches klarer 😀

Neuen Beitrag erstellen
nächster Beitrag/nächster Kommentar
vorheriger Beitrag/vorheriger Kommentar
zeige/verstecke Kommentare
Zum Anfang gehen
zum Login
Zeige/Verberge Hilfe
Shift + ESC