jQuery Validation- und Formplugin

Die 2 jQuery-Plugins lassen sich sehr gut miteinander kombinieren.
Die Anforderung war folgende:

• Valierung auf dem Client -> Validationplugin
  
• Übermittlung des Formulars im Hintergrund (AJAX) -> Formplugin
• So wenig Code wie möglich selber implementieren.

Beide Plugins sind für sicht genommen schon sehr genial.
Das Validationplugin gehört zu den wirklich guten plugins und läßt sich super schnell in die Seite einbauen.

Das nun Folgende Codeschnipsel wurde für Portlets in Form einer JSP konzipiert.
Eine verwendung innerhalb e

<script type="text/javascript" src="${pageContext.request.contextPath}/img/jquery.js"></script>
<script type="text/javascript" src="${pageContext.request.contextPath}/img/jquery.validate.js"></script>
<script type="text/javascript" src="${pageContext.request.contextPath}/img/jquery.form.js"></script>

function validateGutachtenForm() {
$('#gutachtenFormular').validate({
rules: {
kosteneinsparung: "required",
zeiteinsparung: "required"
}, //Ende Regeln
messages: {
},
errorPlacement: function(error, element) {
if ( element.is(":radio") || element.is(":checkbox")) {
error.appendTo( element.parent());
} else {
error.insertAfter(element);
}
},
submitHandler: function(form) {
var options = {
success:       showResponse  // post-submit callback
};
$(form).ajaxSubmit(options);
}
}); // Ende validate
}

// post-submit callback
function showResponse(responseText, statusText, xhr, $form)  {
alert('status: ' + statusText + '\n\nresponseText: \n' + responseText +
'\n\nThe output div should have already been updated with the responseText.');
}

Es gibt verschieden Arten von Buttons in HTML.
An dieser Stelle wir explizit kein Submit-Button verwendet ()
Sondern der button-Tag. Durch betätigen dieses Buttons wird die valierungsMethode aufgerufen.

<button onclick="validateGutachtenForm()">Senden</button>

jQuery erfindet an dieser Stelle das Rad nicht neu, sondern verwendet das class-Attribut
und das title-Attribut.

<input type='radio' name='kosteneinsparung' value='ns'
class='required' title='Wählen Sie eine Option' /> Nicht schätzbar
<input type='radio' name='kosteneinsparung' value='gering' /> Gering
<input type='radio' name='kosteneinsparung' value='mittel' /> Mittel
<input type='radio' name='kosteneinsparung' value='hoch' /> Hoch

Commons Fileupload und Portlet 286

Wir konnten die die Commons-Fileupload lib von Apache nicht in unserer Anwendung verwenden, da die serverRessource-Methode des Porlet286-Standards nicht unterstüzt wird.
Wir haben die Klassen aber fast 1:1 nachgebaut, und um die relevanten Stellen umgeschrieben. Theoretisch könnten wir den Code jetzt contributen, so das Apache Commons-Fileupload dies zukünftig unterstüzten könnte.

Ändern von Comboboxen (SELECT-Tag) über innerHTML

In der Ajax-Welt kommt es häufig vor, dass man die Werte von Comboboxen (also die Options innerhalb eines Select-Tags) dynamisch ändern möchte. Z.B. bei einer Fahrzeugsuche. In der Combobox Marke wird VW ausgewählt. Abhängig davon soll die Combobox Typ mit Golf, Polo, Passat usw. gefüllt werden.

Eine Möglichkeit besteht in der Manipulation des DOMs. Diese Möglichkeit ist aber vor allem im Internet Explorer (IE) sehr imperformant. In den meisten Fällen ist es besser, das HTML, das das Ergebnis der DOM-Operationen sein würde, "von Hand" zu erzeugen und per innerHTML dem Element zu verpassen. Das funktioniert auch in Browsern einwandfrei. Im IE dagegen weit gefehlt.

Der IE hat beim Select-Tag einen Bug (zumindest bis zur Version 7). Wird das Innere eines Select-Tags über innerHTML gesetzt, ist der IE davon unbeeindruckt. Er zeigt weiterhin die alten Einträge in der Combobox.

Hier kommt die IE-spezifische Eigenschaft outerHTML ins Spiel. Verwendet man outerHTML, zeigt der IE die Änderungen nach dem Aufruf auch an.

outerHTML hat zwei unangenehme Nebenwirkungen:

• Der Select-Tag selbst ist auch enthalten. D.h., er muss vollständig im manipulierten String enthalten sein.


• Nach dem Zuweisen von outerHTML wird im DOM eine neue Instanz erzeugt. Um auf das geänderte Element nochmals zuzugreifen, muss es über document.getElementById() wieder geholt werden.

Hier ein Bsp. für die Befüllung eines Select-Tags:

var select = document.getElementById("mySelect");
var num = select.options.length + 1;
select.innerHTML = "";
var innerHTML = "";
// innerHTML erzeugen
innerHTML = "<option value=\"1\">Golf"</option>"
 + "<option value=\"2\">Polo"</option>"
 + "<option value=\"3\">Passat"</option>";

if (isIe()) {
 // nur für IE

 var indexOfClosingTag = select.outerHTML.toUpperCase().lastIndexOf("</select>");
 var outerHTML = select.outerHTML.substring(0, indexOfClosingTag) + innerHTML +  select.outerHTML.substring(indexOfClosingTag);
 select.outerHTML = outerHTML;
 select = document.getElementById(select.id);
} else {
 // nur für Browser
 select.innerHTML = innerHTML;
}
select.styles.display = "";

Der grün markierte Code setzt das erzeugte innerHTML in die vorhandenen Select-Tags ein.

Damit die Zeile select.styles.display = ""; ausgeführt werden kann, muss vorher die neu erzeugt Instanz des Select-Tags aus dem DOM zurückgeholt werden (rote Zeile).

Browser Quirk - Deselect Radiobuttons

Wir haben 2 Gruppen von Radiobuttons.
Wenn die erste Gruppe auf Nein gestellt ist, so muss die zweite Gruppe deselectiert werden. Hierzu gibt es gleich mehrer Dinge zu beachten. Da sich der IE und der FF in diesem Punkt voneinander unterschiedlich verhalten

1. Die Buttons (Gruppe 1) benötigen unbeding onclick="this.blur()" . Damit der Internetexplorer auf die Veränderung reagiert.
   


2. Fehlerhafte indexierung der Buttons im IE.
   

Definition der steuernden Buttons.

<input type="radio" onclick="this.blur()"
onchange="de_wwag_alma_anliegen_versicherungsfallchanged(this.value)"
value="true"
name="editForm:versicherungsfallJaNeinRadio">

<input type="radio" onclick="this.blur()"
onchange="de_wwag_alma_anliegen_versicherungsfallchanged(this.value)"
value="false"
name=":editForm:versicherungsfallJaNeinRadio" >

Deselektieren der abhängigen Buttons.

document.getElementsByName("view<portlet:namespace/>:editForm:versicherungsfallAltNeuRadio")[0].checked = false;
//This is a Browser Quirk - we only have 2 option
//In FF the indexes are 0 and 1
//In IE 0 and 2
document.getElementsByName("editForm:versicherungsfallAltNeuRadio")[0].checked = false;
document.getElementsByName("editForm:versicherungsfallAltNeuRadio")[1].checked = false;
document.getElementsByName("editForm:versicherungsfallAltNeuRadio")[2].checked = false;

Tomcat Authentication: Wie zeige ich den Grund für einen Authentifizierungsfehler an?

Im Tomcat bietet es sich an, die J2EE Authentifizierung für geschützte Resourcen zu verwenden. Das Verfahren ist recht simpel einzurichten und wird auf vielen Seiten im Internet erklärt, z.B. hier.

Diese Einfache Methode der Authentifizierung leitet den User auf eine Login-Seite, falls er eine geschützte Resource aufrufen möchte, aber noch nicht angemeldet ist. Auf dieser Login-Seite wird ein Formular angezeigt, in das er Username und Passwort eingeben muss.


Schlägt die Authentifizierung aus irgend einem Grund fehl, wird der User auf die in der web.xml eingestellte Error-Seite weitergeleitet. In den meisten Anwendungen ist die Error-Seite die Login-Seite mit einem Hinweistext, dass die Authentifizierung nicht möglich war. Manchmal wird noch ein Link angeboten, über den der User sein Passwort zurücksetzen kann.

Bsp:


Das Problem ist jedoch, dass es auch andere Gründe für eine fehlgeschlagene Anmeldung geben kann, außer dass Username oder Passwort falsch eingegeben wurden:

• Passwort ist abgelaufen.


• Passwort wurde zu oft falsch eingegeben.


• Konto wurde wegen Inaktivität gesperrt.


• u.s.w.

Diese Informationen können dem User jedoch bei Verwendung der Standard-Authentifizierung nicht angezeigt werden.

Abhilfe schafft hier die Implementierung eines eigenen Valves zur Form-Authentifizierung. Die Klasse muss von org.apache.catalina.authenticator.FormAuthenticator abgeleitet werden (ganz richtig, das ist eine Tomcat-spezifische Klasse!). In dieser Klasse wird die Methode forwardToErrorPage() überschrieben. Die Methode wird vom Tomcat aufgerufen, nachdem die Authentifizierung fehlschlug und der User zur Error-Seite geleitet wird.

Eine Beispiel-Implementierung:

public class CustomFormAuthenticator extends FormAuthenticator {

 @Override
 protected void forwardToErrorPage(Request request, Response response,
   LoginConfig config) throws IOException {
  Integer errorReason = checkOutErrorReason();
  
  request.setAttribute("loginErrorReason", errorReason);
  super.forwardToErrorPage(request, response, config);
 }

 protected void checkOutErrorReason() {
  //TODO hier die Ermittlung der Ursache für die
  // abgelehnte Authentifizierung implementieren
  return null;
 }

}

In diesem Beispiel wird ein Request-Parameter gesetzt (loginErrorReason), der dann in der Error-Page ausgewertet werden kann.
Bsp.:

Integer errorReason = (Integer) request.getAttribute("loginErrorReason");

Wichtig ist, dass der CustomFormAuthenticator in einem jar im Tomcat/lib-Verzeichnis deployt wird, damit der Tomcat die Klasse findet.

Das Valve muss dann dem Tomcat noch in der Konfiguration im Context der Web-Anwendung (in server.xml) mitgeteilt werden:

     ...
     <Context docBase="myapp" path="" reloadable="true">
        <Valve className="custom.auth.CustomFormAuthenticator" />
     </Context>
     ...

Eine andere Möglichkeit der Konfiguration besteht in der Web-Anwendung in der Datei META-INF/context.xml:

<Context>
 <Valve className="custom.auth.CustomFormAuthenticator" />
</Context>

Danamische AJAX-Tabelle

Basis-Tabelle

<div id="ScrollElement" onscroll="nextElements()"
  style="height: 100px; width: 300px; overflow: auto; border: solid 1px black;">
<table id="tableElement" >
    <thead>
        <tr>
            <th>Item Name</th>
        </tr>
    </thead>
    <tbody>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
       <tr><td>Item</td></tr>
    </tbody>
</table>
</div>
<span id='Debug'></span>

Javascriptcode

<script type="text/javascript">
var global_block = false;
    var global_counter = 0;

    function nextElements()
    {
     var element = document.getElementById('ScrollElement');
     var height = element.scrollHeight;
     var scroll = element.scrollTop;

     var diff = height - scroll;

     document.getElementById('Debug').innerHTML = diff;

     if(diff <= 200 && global_block == false)
     {
         global_block = true;
        appendNewElements();
     }
    }

    function appendNewElements()
    {
     for(var i=0; i<10; i++)
     {
      global_counter++;
      
      var newListElement = document.createElement('tr');

      var tdelement = document.createElement('td');

      var newtext=document.createTextNode('Martin' + global_counter);

      tdelement.appendChild(newtext);
      
      newListElement.appendChild(tdelement);
      
      //newListElement.innerHTML = 'AppendedItem: ' + global_counter;

      var parentElement = document.getElementById('tableElement').getElementsByTagName("TBODY")[0];
            
      parentElement.appendChild(newListElement);


      newListElement = null;
      tdelement = null;
      newtext = null;
      parentElement = null;
     }
     global_block = false;
    }
</script>

Anmerkung.

Dieses Basiskonstrukt läuft im sowohl im Internetexplorer (7) als auch im neuesten Chrome.

JSF ComboBoxen mit Autopostback

Um Dynamische GUIs zu bauen gibt es verschieden Optionen die GUI zu verändern.
In den meisten JSF-Einführungenwird zwar beschrieben wie man ein SelectOne verwendet, jedoch nicht wie man eine Bestimmte logik im Backing bean anspricht.

<h:selectOneMenu id="selectCar" value="#{carBean.currentCar}">
 <f:selectItems value="#{carBean.carList}" />
</h:selectOneMenu>

Der Entscheidende Punkt ist, dass 2 Attribute gesetut werden müssen.
das onchange="this.form.submit()" bewirkt, dass die Werte des Formulars ins Model übernommen werden (durch Aufruf der setter-Methode).
Die Business-Logik sollte man aber nicht in den Setter reinbauen. Sondern sollte mittels eines valueChangeListener eingebunden werden.

<h:selectOneMenu id="selectCar" value="#{carBean.currentCar}"
  valueChangeListener="#{BackingBean.processValueChange}" 
  onchange="this.form.submit()" >
 <f:selectItems value="#{carBean.carList}" />
</h:selectOneMenu>

public void  proessValueChange(ValueChangeEvent event) {
  //some logic
}