Startseite
Tutorial Extension-Entwicklung mit Extbase & Fluid - Teil 8: Dashboard fürs Backend

Teil 8: Ein Dashboard fürs Backend

Click Hier wenn du die Social-Plugins aktivieren willst.

Teil 8:

Ein Dashboard fürs Backend

 

Die große Frage, die sich immer stellt, wenn es ans Implementieren der Schnittstelle mit dem Benutzer geht, ist was man ihm ermöglichen will. Wie man das dann darstellt, ist noch einmal eine anderer Punkt und soll hier hintenanstehen. Ob die Funktion über einen Link oder doch über ein großes buntes Icon präsentiert wird, hat keinerlei Einfluss auf die Funktion selbst, und wir wollen ja hier auch keinen Webdesign Kurs machen.

Wichtig ist aber, welche Funktionen wir überhaupt anbieten wollen, denn als nächstes implementieren wir die Einstiegsseite in unsere Biblio-Anwendung: das Dashboard. Idealerweise kann man für diese Aufgabe den Benutzer für eine gewisse Zeit bei seiner Arbeit beobachten, um zu sehen was er tut. Oder man bekommt vom Auftraggeber wie auch immer geartete Vorgaben. Das haben wir aber alles nicht zur Verfügung, damit greife ich nun auf mein beschränktes Wissen zurück und definiere folgene Aufgaben für das Modul, wie ich sie für sinnvoll erachte:

  1. Ausleihen verwalten
    1. Kunden bringen Dinge zurück
    2. Kunden leihen Dinge aus
    3. Kunden verlängern ihre Ausleihe
  2. Kunden verwalten
    1. Austritte
    2. Eintritte
    3. Daten ändern
  3. Dinge verwalten
    1. Dinge hinzufügen
    2. Dinge entfernen

 

Das sollte in dieser Reihenfolge auch ungefähr der Gewichtung entsprechen. Was nun noch fehlt sind Übersichten, die es den Bibliothekarinnen erlauben, die aktuellen Entwicklungen im Auge zu behalten. So wäre es wahrscheinlich sinnvoll, die für diesen Tag fälligen Rückgaben auf einen Blick zu sehen und vielleicht sogar mit einem Klick erledigen zu können.

Was bisher auch nicht angesprochen wurde: diese Bibliothek hat riesige Karteischränke mit den Daten aller Kunden auf Papier, die sich je in dieser Bibliothek haben registrieren lassen. Die Aufzeichnungen beginnen in den 30er Jahren. Gleiches gilt für die hier bereitgestellten Dinge.

Jetzt denken wir kurz über eine Datenübernahme in unsere Applikation nach und schütteln dann dankend den Kopf. Es ist nicht zu erwarten, dass ein besonders hoher Prozentsatz dieser Daten noch aktuell ist und es würde viel Handarbeit bedeuten. Selbst mit Scannern und Texterkennungssoftware würde es lange dauern, die Daten ins System zu bekommen und das ist gerade die Mühe nicht wert. Statt dessen setzen wir voraus, dass die Kunden einigermaßen entspannt kommen und gehen. Das bedeutet, ein Kunde betritt die Bibliothek, gibt seine Mitgliedskarte am Tresen ab und geht sich umsehen. In dieser Zeit kann die Bibliothekarin die Kundendaten im System erfassen. Kommt der Kunde dann mit seiner Auswahl zurück, werden die auszuleihenden Dinge ebenfalls erfasst. Ja, das kostet Zeit und ich bin mir bewusst, dass das der Realität nicht standhalten würde. Für uns soll es jetzt genügen.

Ich habe dabei auch im Hinterkopf, dass die Bibliothek gerade ihre Räumlichkeiten erweitert. Somit wäre Platz, um die bereits erfassten Dinge in einem Teil der Regale zu halten und die noch nicht registrierten in einem anderen. Nicht alle Dinge werden ja gleichmäßig ausgeliehen, so dass immer zwischendurch, wenn sonst gerade nichts zu tun ist, wieder ein Stapel registriert werden kann, auch wenn gerade keine Ausleihe anliegt. Ziemlich theoretisch das Ganze und für unsere Bibliothekarinnen mit viel Handarbeit verbunden, als Beispiel soll es dennoch genügen.

Was heißt das aber nun für das Dashboard?
Wir brauchen Schnellzugriff auf die Funktionen „Kunde registrieren“ und „Ding registrieren“. Das entspricht den Punkten 2b und 3a aus der oben angegebenen Liste. So könnte es ungefähr aussehen:

Dashboard

Abbildung 1: Das Dashboard

 

Während dieser Überlegungen ist mir aufgefallen, dass für den Betrieb des Moduls der Seitenbaum im Backend nicht nur überflüssig, sondern sogar störend ist. Damit ist das Modul in Web falsch und wäre besser in User-Tools angesiedelt. Die Änderung ist schnell gemacht. Wer weiss wie es geht?

(Lösung: in ext_tables.php den zweiten Parameter der Funktion registerModule() von web zu user ändern. Mögliche Werte gibts in der Doku: TYPO3 Backend Modules.)

 

Gehen wir daran, das Modul zu implementieren.
Fluid liefert einen Satz ViewHelper mit, die speziell für das Backend zugeschnitten sind. Diese haben keine Entsprechung in Flow, denn das kennt ja kein Backend. Ein heißer Tipp übrigens für ViewHelper: statt das Internet nach Doku zu durchsuchen, schau Dir die Klassen an. Im Klassenkommentar stehen bei allen von Fluid mitgelieferten ViewHelpern ausführliche Verwendungshinweise. Da sie gleichzeitig mit eventuellen Änderungen am Code von den Entwicklern selbst geschrieben werden, gibt es keine aktuellere Informationsquelle. Eine gute Inspiration sind Systemextensions, die inzwischen auf Fluid umgestellt wurden. Belog und beuser gehören zu denen, bei denen ich am liebsten abschreibe.

Der erste, der für uns zum Einsatz kommt, ist der Container ViewHelper. Er stellt die Backend spezifischen Styles zur Verfügung und includiert auch JavaScript Bibliotheken. Er umfasst die gesamte Ausgabe und kommt deshalb in die Layout-Datei Resources/Private/Layouts/Default.html. Das eigene wrapping div brauchen wir damit nun nicht mehr.

<f:be.container pageTitle="Biblio Management" loadPrototype="FALSE" loadExtJsTheme="FALSE" includeCssFiles="{0: '{f:uri.resource(path:\'Css/style.css\')}'}" loadJQuery="true">
	<f:render section="main" />
</f:be.container>

 

Damit wird dafür gesorgt, dass wir jQuery zur Verfügung haben und eine eigene Style Datei geladen, die in Resources/Public/Css liegt und style.css heisst. Diese ist vorläufig leer. Um sicherzustellen, dass sie geladen wird, kann man da testweise eine rote Hintergrundfarbe für den body definieren, das fällt dann auf.

Um erst einmal etwas Grund hineinzubringen, werden im Index Template fünf Blöcke definiert und mit CSS positioniert. Überschriften können dabei direkt mit angelegt werden. Ich verzichte hier auf jede Art von state of the art frontend design tools und frameworks und verwende reines CSS. Die Label, die das Modul verwendet, werden direkt für mehrsprachige Anwendungen definiert und in eine eigene Sprachdatei ausgelagert. Es hat sich (fuer mich) bewährt, gar nicht erst mit statischen Texten in Templates anzufangen. Das Template (Resources/Private/Templates/Biblio/Index.html):

<div xmlns="http://www.w3.org/1999/xhtml" lang="en"
	 xmlns:f="http://xsd.helmut-hummel.de/ns/TYPO3/CMS/Fluid/ViewHelpers">
	<f:layout name="Default"/>
	<title>Templates: Index</title>
	<f:section name="main">
		<h1>Biblio Management Dashboard</h1>
			<div class="widget_1">
				<h2><f:translate key="widget_1" /></h2>
			</div>
			<div class="widget_2">
				<h2>
					<f:translate key="widget_2"/>
				</h2>
			</div>
			<div class="widget_3">
				<h2>
					<f:translate key="widget_3"/>
				</h2>
			</div>
			<div class="widget_4">
				<h2>
					<f:translate key="widget_4"/>
				</h2>
			</div>
			<div class="widget_5">
				<h2>
					<f:translate key="widget_5"/>
				</h2>
			</div>
	</f:section>
</div>

 

Die Sprachdatei (Resources/Private/Language/locallang.xlf):

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<xliff version="1.0">
	<file source-language="en" datatype="plaintext" original="messages" date="2013-03-16T22:23:40Z"
		  product-name="biblio">
		<header/>
		<body>
			<trans-unit id="widget_1">
				<source>Fast Access</source>
			</trans-unit>
			<trans-unit id="widget_2">
				<source>Today</source>
			</trans-unit>
			<trans-unit id="widget_3">
				<source>In &amp; Out</source>
			</trans-unit>
			<trans-unit id="widget_4">
				<source>Clients</source>
			</trans-unit>
			<trans-unit id="widget_5">
				<source>Inventory</source>
			</trans-unit>
		</body>
	</file>
</xliff>

 

und der Vollständigkeit halber die CSS-Datei (Resources/Public/Css/style.css):

 

body {
	padding: 2%;
}

.widget_1, .widget_2 {
	padding: 1%;
	width: 44%;
	border: 1px solid;
	margin: 15px;
	float: left;
}

.widget_3, .widget_4, .widget_5 {
	padding: 1%;
	width: 28%;
	border: 1px dashed;
	margin: 15px;
	float: left;
}

 

Das ergibt das gleiche Bild wie im Diagramm vom Anfang. Damit können wir nun die Implementierung fortsetzen. Weiter geht es dann im nächsten Beitrag mit der Kundenverwaltung.

 

Übrigens, wer das alles gerne mal kompakt in einem Kurs lernen würde, bei der typovision academy biete ich auch eine Schulung zum Thema an: TYPO3 Extbase/Fluid-Schulung für Einsteiger. Der nächste Kurs findet Anfang Oktober statt.

 

Beitrag verpasst?
Extension-Entwicklung mit TYPO3 Extbase & Fluid

Teil 1: Entstehung der Blogreihe, Idee & Datenmodellierung
Teil 2: Das Grundgerüst
Teil 3: Implementierung
Teil 4: Implementierung Kunden Model
Teil 5: Implementierung Model Bibliothek
Teil 6: Implementierung Bibliothekscontroller & Backendmodul für die Verwaltung
Teil 7: Fluid – die Templating Engine

 

4 Gedanken zu “Teil 8: Ein Dashboard fürs Backend

  1. Patrick Schriner

    Schöner Beitrag! Habe so etwas gerade heute gesucht

    Unten der 6te Link funktioniert nicht, da steht http://http//

    Kommentar
  2. Die komplette Blog-Reihe ist exzellent!
    Konzentriert auf das Wesentliche.
    Die Seitengedanken ebenfalls wesentlich und sinnvoll.
    Und alles auch noch unterhaltsam.
    Chapeau Madame!
    Petra von Rhein

    Kommentar
  3. Daniel Ziegenberg

    Wann kommt der nächste und 9. Teil?

    mfg, Daniel

    Kommentar
    1. Sabine Mayr sabine

      Hi Daniel, wir schaffen es gerade zeitlich nicht an der Blogreihe weiterzuarbeiten. Ich muss Dich leider erst einmal auf unbestimmte Zeit vertrösten… Wir bleiben aber dran LG Sabine

      Kommentar

Hinterlasse einen Kommentar zu Sabine Mayr Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>