formats

Javascript: Ladebildschirm mit Dojo und CSS realisieren

Ausgestellt am 25. September 2011 vom in Javascript

Dieser Artikel zeigt eine Möglichkeit einen Ladebildschirm mit Hilfe von Dojo und CSS zu realisieren. Aufgabe des Ladebildschirms ist es den Benutzer darüber zu informieren, dass der Browser noch mit dem Verarbeiten der geladenen Seite beschäftigt ist. Um dies zu realisieren werden lediglich ein paar Dojo Funktionen, ein wenig CSS und eine animierte Grafik benöitgt.

Der unten stehende Quellcode stammt aus einer einfachen HTML Datei, welche für diesen Artikel als Beispiel dienen soll. Zeile acht und zehn binden die CSS Datei und das Dojo Framework ein. Über die CSS Definitionen wird das Aussehen und die Grafik des Ladebildschirms beschrieben. Dojo wird eingebunden um festzustellen, wann der Ladebildschirm gestartet/deaktiviert werden muss. In Zeile 12 bis 21 befindet sich die Dojo Javascript Funktion, die alles erst möglich macht. Sie befindet sich im Header der HTML Datei und überwacht das Parsen der Seite im Browser. Beim Parsen der Seite durch den Browser aktiviert das Script den Ladebildschirm und deaktiviert diese erst, wenn die Seite vollständig geparst wurde und dargestellt werden kann. Das deaktivieren der Animation wird über loader.style.display = “none”; erreicht. Damit werden die CSS Eigenschaften der Animation auf unsichtbar gesetzt, wodurch der Browser diese nicht mehr darstellt. Das ganze passiert in diesem Beispiel mit einer Verzögerung von 1000 Millisekunden und einem fade out Effekt.

Zeile 27 zeigt die HTML Tags, die mit Hilfe des CSS zu einer Ladeanimation werden. Wichtig ist, dass diese direkt nach dem Body Tag zum Einsatz kommen, damit sie als erstes vom Browser geparst werden.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="de">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

	<title>Beispiel eines Ladebildschirms mit Dojo und CSS</title>

	<link rel="stylesheet" href="style.css" />	

	<script src="http://ajax.googleapis.com/ajax/libs/dojo/1.6.1/dojo/dojo.xd.js" type="text/javascript"></script>

	<script type="text/javascript">
		dojo.require("dojo.parser");
		dojo.addOnLoad(function(){
			dojo.parser.parse(document.body);
			setTimeout(function(){
				var loader = dojo.byId("loader");
				dojo.fadeOut({ node: loader, duration: 1000, onEnd: function(){ loader.style.display = "none"; }}).play();
			}, 1000);
		});
	</script>		  	

</head>

<body>

<div id="loader"><div id="loaderInner"></div></div>

<div><p style="text-align:center;">Dieser Text wird erst angezeigt, wenn das Dokument komplett geladen wurde.</p></div>

</body>
</html>

Kommen wir nun zu den CSS Eigenschaften des Ladebildschirms. Sie sorgen dafür, dass dieser das ganze Browserfenster füllt und die benötigte Animation in Form eines Gifs eingebunden wird. Die erste CSS Definition bewirkt, dass der ganze Bildschirm mit einem grauen Farbton hinterlegt wird. Über z-index:999; wird der Ladebildschirm auf die oberste Ebene des HTML Dokumentes gelegt. Damit überdeckt er alle darunter liegenden Ebenen.

Die zweite CSS Definition positioniert das animierte Gif in der Mitte des Bildschirms. Schließlich wird noch der Pfad zum Gif angegeben. In diesem Beispiel handelt es sich um einen animierten Kreis der dem Benutzer den Eindruck vermittelt, dass der Browser noch mit dem Verarbeiten der Seite beschäftigt ist. Das benutzte Gif in diesem Beispiel kann natürlich durch jede beliebige andere Animation ersetzt werden. Es sollte jedoch darauf geachtet werden, dass die CSS Eigenschaften an die Größe des jeweiligen Bildes angepasst werden.

#loader {
	padding:0;
	margin:0;
	position:absolute;
	top:0; left:0;
	width:100%; height:100%;
	background:#efefef;
	opacity: 0.98;
	z-index:999;
	vertical-align:middle;
}
#loaderInner {
	position: absolute;
	top: 50%;
	left: 50%;
	width: 32px;
	height: 32px;
	margin-top: -16px;
	margin-left: -16px;
	background-image: url("images/loading_animation.gif");
	background-repeat: no-repeat;
}

Das in diesem Artikel beschriebene Beispiel kann hier betrachtet werden. Der beschriebene Ladebildschirm ist recht einfach gehalten und bietet noch viel Spielraum für Verbesserungen und kreative Designs.

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Spring: Dojo im Einsatz – Teil I

Ausgestellt am 7. August 2011 vom in Spring Framework

Bei Dojo handelt es sich um ein professionelles Javascript Framework, welches dem Entwickler zahlreiche UI Widgets zur Verfügung stellt. Bei den Widgets handelt es sich beispielsweise um eine Kalendar-Komponente, einen WYSIWYG-Editor, einen Fortschrittsbalken, verschiedene Diagrammtypen, Menüs und vieles mehr. Dies ist lediglich ein kleiner Auszuug von den UI-Komponenten, die zur Verfügung stehen. Eine vollständige Auflistung aller Komponenten inklusive Beispiel ist auf dieser Seite zu finden. Alle Dojo-Komponenten lassen sich umfangreich an die jeweiligen Bedürfnisse anpassen. Hierfür steht dem Benutzer eine API zur Verfügung, die auf dieser Seite beschrieben wird.

Über das Modul Spring JS bietet das Spring Framework dem Entwickler die Möglichkeit die einzelnen Dojo-Widgets in die eigene Webanwendung einzubinden. Spring JS ist ein Teil von Spring Webflow und abstrahiert die Verwendung des darunter liegenden Javascript-Frameworks. Als Standard kommt bei SWF Dojo zum Einsatz. Jedoch lassen sich auch andere Javascript-Frameworks einbinden, wie beispielsweise jQuery.

Ein Vorteil eines solchen Javascript-Frameworks ist, dass sich der Entwickler nicht mehr um die Erstellung komplexer UI-Komponenten kümmern muss. Dies spart eine Menge Zeit, da es sehr aufwendig ist Komponenten zu entwickeln, die in allen Browsern korrekt funktionieren und dargestellt werden. Er kann sich stattdessen vollständig auf die Implementation der Logik konzentrieren.

Konfiguration

Dojo lässt sich in Spring auf folgende Art und Weise konfigurieren, vorrausgesetzt das ResourceServlet wurde in Spring korrekt konfiguriert.

<script type="text/javascript" src="<c:url value="/resources/dojo/dojo.js"/>"></script>
<script type="text/javascript" src="<c:url value="/resources/spring/Spring.js"/>"></script>
<script type="text/javascript" src="<c:url value="/resources/spring/Spring-Dojo.js"/>"></script>
<link type="text/css" rel="stylesheet" href="<c:url value="/resources/dijit/themes/tundra/tundra.css"/>"/>

Die Zeilen 1-3 laden die entsprechenden Javascript-Dateien, die für die Verwendung des Dojo-Frameworks in Verbindung mit Spring benötigt werden. Zeile 4 gibt an, welches Theme für die Dojo-Widgets benutzt werden soll. In dem Beispiel wird das Theme Tundra geladen. In der aktuellen Version 1.6 stehen vier Themes zur Auswahl:

  • claro
  • tundra
  • soria
  • nihilo

Beispiele für das Aussehen der einzelnen Themes sind hier zu sehen.

Dropdown Widget

Das folgende Beispiel zeigt, wie mit Hilfe von Spring und Dojo eine Select-Box erstellt wird. Die ersten vier Zeilen definieren die Formular-Komponente mit Hilfe von Spring Forms. Beim Abschicken des Requests wird das ausgewählte Element der Select-Box in der Beanvariable mitarbeiterVar gespeichert. Der Formular-Komponente wird eine ID mitarbeiterSelect zugeordnet über welche diese später mit Dojo-Eigenschaften angereichert wird. Die Zeilen zwei bis drei füllen die Select-Box schließlich mit Elementen. In diesem Beispiel handelt es sich um Namen von Mitarbeitern, die in einer Liste von String-Objekten  (mitarbeiterListe) gespeichert sind. Über das JSTL-Tag c:forEach wird die Liste durchlaufen und die Select-Box gefüllt.

In Zeile 7-14 wird die Select-Box schließlich um Dojo-Eigenschaften erweitert, so dass diese später wie ein Dojo-Widget aus den Beispielen aussieht. Die ID, die wir zurvor vergeben haben, kommt hier wieder zum Einsatz. Über elementId wird Dojo mitgeteilt, welches HTML-Element angereichert werden soll. Wichtig ist, dass die vergebenen IDs immer eindeutig sein müssen. Verschiedenen Komponenten die gleichen IDs zu geben, führt in den meisten Fällen zu Problemen mit Dojo. Über widgetType geben wir an, welches Dojo-Widget auf die vorher definierte Select-Box angewendet werden soll. dijit.form.FilteringSelect ist das entsprechende Widget für eine Select-Box, welche beispielsweise um eine Auswahlvervollständigung erweitert wird. Über required: true wird festgelegt, dass beim Abschicken eines Formulars die Auswahl der Select-Box nicht leer sein darf. Das Abschicken würde in diesem Fall fehlschlagen. Die nächste Zeile gibt an, wie Breit das UI-Widget sein soll. Über das style-Attribut kann das Aussehen der Komponente über CSS-Eigenschaften angepasst werden.

<form:select path="mitarbeiterVar" id="mitarbeiterSelect">
<c:forEach items="${mitarbeiterListe}" var="mitarbeiter">
	<form:option value="${mitarbeiter}">${mitarbeiter}</form:option>
</c:forEach>
</form:select>
<script type="text/javascript">
Spring.addDecoration(new Spring.ElementDecoration({
	elementId: 'mitarbeiterSelect',
	widgetType: 'dijit.form.FilteringSelect',
	widgetAttrs : {
		required: true,
		style: "width: 12em;"
	}
}));
</script>

Kalendar Widget

Eine Kalendar-Komponente mit Dojo zu erstellen ist recht unkompliziert. Alles was wir hierfür benötigen ist ein Input-Formular. Dieses wird in Zeile eins über Spring-Forms definiert. Wie gewohnt vergeben wir auch für diese Formular-Komponente eine eindeutige ID.  Ab Zeile vier reichern wir die Input-Komponente wieder um Dojo-Eigenschaften an. In diesem Fall nutzen wir jedoch ein anderes Dojo-Widget, nämlich dijit.form.DateTextBox. Über das Attribut datePattern wird das Format des Datums angegeben. In diesem Fall entscheiden wir uns für das Format yyyy-MM-dd, welches z.B. dem Datum 2011-12-18 entsprechen würde. Das Datumsformat lässt sich an die jeweiligen Bedürfnisse und Zeitzonen anpassen. Auch diese UI-Komponente akzeptiert keine leeren Eingaben (required: true). Schließlich geben wir für die Komponente noch eine Breite an. Das ist eigentlich auch schon alles, was an Konfiguration notwendig ist. Beim Abschicken des Formulars wird das ausgewählte Datum in der Beanvariable startDate gespeichert und bei Bedarf von Spring in ein Date-Objekt überführt.

<form:input path="startDate" id="startDate"/>
<script type="text/javascript">
Spring.addDecoration(new Spring.ElementDecoration({
	elementId : 'startDate',
	widgetType : 'dijit.form.DateTextBox',
	widgetAttrs : {
		required : true,
		datePattern : 'yyyy-MM-dd',
		style: "width: 12em;"
	}
}));
</script>

Button Widget

Die letzte UI-Komponente von Dojo, die in diesem Artikel vorgestellt werden soll ist dijit.form.Button. Ein Button wird in Formularen in den meisten Fällen dazu genutzt, um die angegebenen Formulardaten abzuschicken, so dass diese von einem Skript im Hintergrund weiterverarbeitet werden können. In diesem Beispiel wird ein einfacher Submit-Button erstellt (ohne Spring Forms). Wie gewohnt wird auch hier wieder eine ID vergeben. Über das Attribut label können wir dem Button einen Text verpassen. In Zeile 12 wird es wieder ein wenig interessanter. Dort definieren wir einen Validator für das Abschicken des Formulars. Dieser Validator wird über die elementId an den vorher definierten Button gebunden. Er wird ausgelöst, sobald ein Benutzer auf den Button klickt. Dies wird über event: ‘onclick’ festgelegt. Klickt ein Benutzer auf den Button, so wird eine Clientseitige Validation des Formulars durchgeführt. Clientseitig meint in diesem Fall, dass die Überprüfung im Browser statt findet. Es wird daraufhin überprüft, ob alle notwendigen Formular-Komponenten ausgefüllt wurden. Ob eine Komponente leer sein darf oder nicht, wurde in den vorangegangenen Beispielen über das Attribut required: true definiert. Zusätzlich dazu wird überprüft, ob die jeweiligen Eingaben valide sind (z.B. ob das Datumsformat des Kalendars korrekt eingegeben wurde).

<input type="submit" value="Abschicken" id="submitButton" />
<script type="text/javascript">
Spring.addDecoration(new Spring.ElementDecoration({
        elementId : "submitButton",
        widgetType : "dijit.form.Button",
        widgetAttrs : {
                label:"Abschicken"
        }
}));
</script>
<script type="text/javascript">
Spring.addDecoration(new Spring.ValidateAllDecoration({
	event : 'onclick',
	elementId : 'submitButton'
}));
</script>
 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Java: Best Practice – Teil I

Ausgestellt am 25. Juli 2011 vom in Java

Lazy initialization

Das Erstellen von Objekten in Java ist eine der kostspieligsten Operationen in Hinblick auf Performance und Speicherverbrauch. Aus diesem Grund sollten Objekte nur dann erzeugt werden, wenn sie auch gebraucht werden. Diese Art der Objekterzeugung wird als lazy initialization bezeichnet. Eine Möglichkeit es zu implementieren könnte beispielsweise so aussehen:

public class Mitarbeiter {

     private List mitarbeiter = null;

     public List getMitarbeiter() {

          //Liste nur initialisieren, wenn sie benötigt wird
          if (mitarbeiter == null) {
               mitarbeiter = new ArrayList()
          }
          return mitarbeiter;
     }
}

Lazy initialization ist besonders sinnvoll beim Erzeugen von Listen und Arrays. Diese Art der Objekterzeugung sollte jedoch vermieden werden, wenn das Erstellen des Objektes mit komplexeren Berechnungen verbunden ist. In so einem Fall sollte das Objekt und dessen eventuelle Unterobjekte vor dem eigentlichen Gebrauch erzeugt werden. In allen anderen Fällen sollte lazy initialization verwendet werden, um Speicher und Rechenzeit zu sparen.

Primitive Datentypen vs. Wrapper Klassen

Wrapper Klassen sind relativ neu in Java und sehr hilfreich. Java wandelt diese zur Laufzeit automatisch in ihre jeweiligen Primitiven Datentypen um und umgekehrt. Das hat zur Folge, dass Wrapper Klassen mehr und mehr eingesetzt werden. Trotzdem sollte man verneiden sie einzusetzen, wenn es nicht unbedingt notwendig ist. Ein Grund ist die Performance. Primitive Datentypen speichern lediglich einen Wert, wohingegen eine Wrapper Klasse neben dem Wert noch andere Objekteigenschaften im Speicher hält. Ein weiterer Grund ist die erhöhte Fehleranfälligkeit des Codes beim Einsatz von Wrapper Klasse.

Ein Beispiel, welches die unerwarteten Resultate beim Einsatz von Wrapper Klassen demonstriert, ist im nächsten Beispiel zu sehen:

//Primitive Datentypen
int primitiveX = 10;
int primitiveY = 10;

//Wrapper class für int
Integer wrapperX = new Integer(10);
Integer wrapperY = new Integer(10);

//Ergebnis ist wahr
System.out.println(primitiveX == primitiveY);
//Ergebnis ist falsch
System.out.println(wrapperX == wrapperY)

Der erste Vergleich liefert als Ergebnis true, da dort zwei primitive Datentypen mit dem gleichen Wert verglichen werden. Beim zweiten Vergleich ist das Ergebnis false, obwohl auch hier der Wert beider Wrapper-Objekte gleich ist. Nur werden hier keine zwei Werte verglichen, sondern die Referenzen der beiden Objekte. Dieser kleine Unterschied führt zu zwei sehr unterschiedlichen Ergebnissen und kann in einem Programm zu schwer nachvollziehbaren Fehlern führen.

Das zweite Beispiel zeigt, dass man beim Einsatz von Wrapper Klassen nicht vergessen sollte, diese zu initialisieren. Das folgende Beispiel würde nichts auf der Konsole ausgeben, sondern statt dessen eine NullPointerException werfen. Wenn man sich noch einmal ins Gedächtnis ruft, dass Wrapper Klassen Objekte sind, dann wird die Fehlerquelle sofort klar. In der if-Abfrage wird versucht auf ein nicht initialisiertes Objekt zuzugreifen, welches den Wert null besitzt und demzufolge eine NullPointerException geworfen.

Boolean test;

if(test == true || test == false) {
    System.out.println("Testvariable hat einen Wert.");
}

Konkatenierung von String-Objekten

Die Konkatenation von String-Objekten mit Hilfe des “+”-Operators in Java ist eine kostspielige Angelegenheit. Bei jeder Konkatenation erzeugt Java Kopien der zu kopierenden String-Objekte, was zu einer schlechten Performance und einem erhöhten Speicherverbraucht führt. Will man mehrere String-Objekte miteinander verbinden, so sollte man dies über die StringBuffer-Klasse machen. Auf diese Weise wird vermieden, dass unnötige Kopien erzeugt werden, sowie eine höhere Performance gewährleistet. Ein Beispiel für die Verwendung der StringBuffer-Klasse seht ihr hier:

StringBuffer strBuf = new StringBuffer();
strBuf.append("Auf diese Weise");
strBuf.append("lassen sich Zeichenketten");
strBuf.append("ressourcen schonender Verbinden.");
System.out.println(strBuf.toString());

Leere Collections und Arrays

Die Klasse java.util.Collections besitzt einige Hilfreiche Methoden, die einem das Leben bei der Arbeit mit Collections und Arrays erleichtern. Besonders bei Methoden, die eine Collection oder ein Array zurückliefern, machen die Hilfsmethoden Sinn. Man sollte vermeiden bei solchen Methoden null zurückzugeben. Statt dessen sollte eine leere Collection bzw. ein leeres Array zurückkommen. Auf diese Weise muss beim Aufruf der Methode nicht überprüft werden, ob null zurückgegeben wurde. Man spart sich also eine Überprüfung des Rückgabewertes auf null und vermeidet zusätzlich eine weitere Fehlerquelle, die eventuell zu einer NullPointerException geführt hätte. Zwei Hilfsmethoden der Collections-Klasse sind unten aufgeführt. Sie liefern jeweils automatisch den korrekten Typ der Collection zurück.

public List getNameList() {
     if (nameList == null)
          return Collections.emptyList();
     return nameList;
}

public HashMap getNameHashMap() {
     if (nameHashMap == null)
          return Collections.emptyMap();
     return nameHashMap;
}
 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
© chuckandwayne Blog
credit