Hm, ein bischen knapp, die Zeit. Peter war schon länger auf der Suche nach einer geigneten Software, was er fand war zu teuer und musste trotzdem noch angepasst werden.

Wie wärs mit einer Erfassungssoftware auf Basis von TYPO3?

Ziemlich leichtfertig, mein Vorschlag, immerhin war noch keine Zeile Code geschrieben! Peter war sofort angetan, ja mach mal! Oh, je, jetzt hatte ich die Sache am Hacken. Keine Zeit verlieren, Radfahren und Freizeit fällt wohl ertsmal aus. Dank der Großzügigkeit des Haupstpsonsors Rhön Sprudel standen uns kurzerhand 4 Laptops und 1 Server zur Verfügung. Den Server habe ich mit Linux und Typo3 startklar gemacht und angefangen die Software als TYPO3- Extension zu entwickeln.

Der Tag der Wahrheit..

war gestern! Ja ich lebe noch, der Supergau blieb aus und ich konnte mich sogar noch auf dei 58km Mountainbike-Runde begeben. Alles funktionierte prima, keine langen Wartschlangen und jeder Teilnehmer bekam seine Startnummer mit Namen ausgedruckt. Wir hatten im Vorfeld alle vorhandenen Daten ins System importiert, so daß die Vereinsmitglieder zum überwiegenden Teil nur Starter, Strecke auswählen und  “Startnummer drucken” mussten. Neue Teilnehmer konnten über ein Kontaktemenü veranstaltungsunabhängig erfasst werden. Sie stehen danach ebenfalls im Auswahlfeld für alle Veranstaltungen zur Verfügung. Natürlich können auch neue Veranstaltungen und Strecken angelegt werden.

Wie gehts weiter?

Die nächste Veranstaltung findet im Juni statt und die Software bekommt den nächsten Entwicklungsschritt. Die Erfassung von ca 600 Daten direkt am Veranstaltungstag war problemlos, jedoch gibt es einige Verbesserungsmöglichkeiten. So ist z.B. die Teilnehmerauswahl aus einem Pulldownmenü (select) bei mehr als 1500 Datensätzen etwas mühsam, da man zur Vorauswahl nur die ersten beiden Zeichen eingeben kann. Hier denke ich an ein Vorschlagssystem ähnlich wie bei Google.
Da muss ich mich wohl mal näher mit AJAX beschäftigen.

Es bleibt spannend!

Version: tt_news 2.5.2

Neeeeeeeeee!
Warum nur zeigt die AMENU Ansicht alle News (auch die 2010er) an?
Wie in Bild1 zu sehen ist werden alle 2010er Einträge angezeigt. Damit nicht genug, klickt man dann auf einen der Einträge, sollte eine Listenansicht mit entsprechenden Einträgen erscheinen. Tut sie aber…..nur teilweise. Bei den 2009er Einträgen und älter funktioniert es so wie zu erwarten. Bei den 2010er eben nicht (Bild2). Das ist auch zu erwarten, da diese Einträge ja noch nicht archiviert sind.

Seit Stunden probiere ich alle Einstellungen . Es ist doch unlogisch, in einem Archiv sollen bitte auch nur die archiverten Einträge zu sehen sein. Ist das noch niemandem aufgefallen?
Doch! Glücklicherweise bin ich auf folgenden Blog gestoßen: münster-webdesin.net. Hier habe habe ich eine Lösung gefunden. Nochmal, herzlichen Dank dafür!

Lösung:
Im TS sollte folgende Eintrag gesetzt werden:

plugin.tt_news.enableArchiveDate = 0

Standardmäßig steht es auf 1. Nun sehe ich in meiner Archivansicht schön alle Einträge, die älter als ein Jahr sind.
So soll es sein!

Das PDF zum Download gibt es hier:
http://www.mittwald.de/extbase-dokumentation

Extbase, die moderne Art, Typo3 Extensions zu programmieren. Klingt gut, schließlich will ja jeder auf der Höhe der Zeit sein.  Extbase ist eine TYPO3 Extension, die schon jetzt die Möglichkeit bietet, Extensions im Stil der kommenden Version 5 von Typo3 und FLOW3 zu entwickeln. Stichworte sind hier MVC (Model-View-Controller) und DDD (Domain-Driven-Design). Ergänzt wird das Ganze noch mit Fluid, einer neuen intuitiven Template-Engine.  Aber ist das Neue auch das Bessere? Ich habe diese Frage für mich mit einem dicken JA beantwortet!

MVC ist zunächst ein Design Pattern, also eine bestimmte Art, seine Softwareentwicklung zu strukturieren. So werden bestimmte Bereiche zusammengefasst. Das Model enthält die Datenorganisation, der View erzeugt die Datenausgabe, der Controller steuert und verarbeitet die Datenströme zwischen Model und View.  Das sorgt für sauberen gut wartbaren Code, da z. B. im Controller kein HTML und im View keine Prozesslogik (PHP) enthalten ist. Das z. B. erleichtert auch die Arbeitsteilung, da der Designer nur den View bearbeitet und keine PHP Kenntnisse benötigt.

Hier meine Erfahrungen…

Infos
holte ich mir in den Fachartikeln der t3n:
Die Zukunft der Extensionentwicklung, von Jochen Rau
Fluid: Templating leicht gemacht, von Sebastian Kurfürst
Extension-Entwicklung mit Extbase und Fluid, von Patrick Lobacher
und schaute mir die hervorragende Präsentation von Jochen Rau und Sebastian Kurfürst an (siehe oben).

Als nächstes besorgte ich mir die Dokumentation Extbase als PDF und installierte extbase und fluid, beides ist bei Typo3 4.3 an Bord. Danach “wühlte” ich mich durch die o. g. Doku, was etwas mühsam war, denn sooo gut ist mein Englisch auch nicht. Immerhin zwingt es zum genaueren mehrmaligen Lesen, was für das Verständnis sehr förderlich ist.

Weitere Vorbereitungen
In der Doku wird die Beispiel-Extension eines Blogs vorgestellt. Also habe ich mir blog_example und auch gleich eine leere efempty als Arbeitsgrundlage installiert.
Nachdem ich mein erstes Erfolgserlebnis mit der Blogextension hatte, wollte ich selbst gleich mal etwas eigenes auf die Beine stellen. Warum nicht eine ganz einfache Adressverwaltung mit nur einer Datenbanktabelle.

Extbase Kickstarter – sowas gibt es auch schon?
Irgendwo habe ich darüber etwas gelesen – wo kriege ich das Ding jetzt her? Der Extbase Kickstarter ist in einer frühen Entwicklungsphase und im TER (noch) nicht verfügbar. Den Kickstarter gibts bei Typo3 Forge  als Subversion unter: http://forge.typo3.org/repositories/show/extension-extbase_kickstarter
Ach ja, herunterladen kann man das auch nicht so einfach, man braucht dafür einen SVN Client z. B. SmartSVN, Subclipse (Eclipse Plugin, meine Wahl).

Wie der Kickstarter funktioniert, zeigt das Video von Sebastian Kurfürst:
Scaffolding width the Extbase Kickstarter

Meine erste Extbase Extension in 5 Minuten
Gebannt hockte ich vor dem Video und erlebte, wie schnell man sich sein Datenmodel “zusammenklicken” kann. Also los, einen Extension Key vergeben und ein kleines Datenmodel “Company” mit den üblichen Eigenschaften: Name, Anschrift, PLZ, Ort, Telefon usw. erstellen.  Das Ganze abgespeichert und meine neue Extension im Ext-Manager vorgefunden. Dann installiert, es wurde eine Tabelle angelegt. Meine Extension als Inhaltselement in eine TYPO3 Seite eingebunden, die Seite als Ausgangspunkt gewählt. Über die Listenansicht habe ich dann einfach 2 Datensätze angelegt. Den Cache leeren und die Seite aufrufen und staunen!!!

Mir bot sich eine Liste, in der die Datensätze editiert, gelöscht und neu angelegt werden konnten. Die Liste und die Formulare waren schon da!

Moment mal, was ist mit den Controllern und den Templates?
Die hatte ich doch noch gar nicht erstellt! Tja, das ist die Magie von Extbase, es bringt seine eigenen Standardcontroller und Ausgaben schon mit. Wie genial ist das denn?

Für eine schnelle erste Ausgabe meiner Extension brauche ich also nur das M von MVC. Alles weitere kann man sich dann entwickeln, eigene Controller, Templates usw. Das habe ich dann auch getan und zunächst nur die Templates mit Fluid gebastelt, die Standard-Controller genügten mir, vorerst. Ich habe mir die Templates in der Blog Extension angeschaut. Fluid is so intuitiv aufgebaut, dass ich mir meine einfachen Templates gleich ohne die Doku erstellen konnte, super!

<h1>Firmen</h1>
<p><f:link.action action="new">Neu</f:link.action> | <f:link.action action="index">Liste</f:link.action></p>
<table>
 <th>Kd-Nr</th><th>Firma</th><th>Anschrift</th><th>Telefon/Mobil</th><th></th>
 <f:for each="{companies}" as="company">
 <tr>
 <td>{company.kdnr}</td>
 <td>{company.name}</td>
 <td>{company.address}<br/>{company.postalcode}&nbsp;{company.city}<br/></td>
 <td>{company.phone}<br/>{company.mobile}</td>
 <td><f:link.action action="edit" arguments="{company : company}">Bearbeiten</f:link.action>&nbsp;
 <f:link.action action="delete" arguments="{company : company}">Löschen</f:link.action></td>
 </tr>
 </f:for>
</table>

Template für die Liste

Extbase Namenskonvention
Sehr hilfreich ist auch die Namenskonvention von Extbase. Sie erleichtert die Orientierung erheblich. So bilden sich die Klassennamen aus der Verzeichnisstruktur:

Tx_BlogExample_Controller_BlogController -
blog_example/Classes/Controller/BlogController.php

Ähnliches gilt für die Controller Methoden und die zughörigen Templatenamen

indexAction() - index.html
newAction() - new.html

Mein Fazit:
Extensions entwickeln macht mit Extbase richtig viel Spaß. Man kann sich auf die wesentlichen Dinge seiner Programmierung konzentrieren. Standardaufgaben wie z. B. Datenbankinteraktionen oder Formularvalidierungen stehen bereits zur Verfügung, so dass man sich damit nicht aufhalten muss. Dass man schon in 5 min. eine funktionierende Extension erstellen kann, die nach weiteren 5 min. für einfache Fluid-Templates ein eigenes Layout besitzt, ist einfach nur begeisternd. Meine erste Extbase Extension funktioniert und ich kann mich nun in Ruhe dem Studium der Dokumentationen widmen, um dann auch anspruchsvollere Projekte anzugehen.

Ausgabe meiner ersten Extbase Extension mit einfachem Fluid Template

Bearbeitungsansicht

TYPO3 Datensätze über das Frontend löschen

Ich entwickle gerade ein kleines CRM mit Kunden-, Kontakt-, Webaccount- und Dokumentenverwaltung auf Basis von TYPO3. Als Extension bietet die Anwendung standardmäßig die Pflege der Daten über das Backend. Auf Dauer war mir das zu umständlich und ich habe mit der Entwicklung einer Verwaltung über das Frontend begonnen. Dabei bin ich auf folgenden Grundsatz gestoßen.

“TYPO3 löscht keine Daten!”

Die einschlägige Literatur zum Thema Extensions behandelt das Thema sehr oberflächlich indem häufig nur die API Funktion exec->DELETEquery() kurz aufgelistet wird. Betrachtet man die Datenbanktabellen in TYPO3 näher, stellt man fest, das alle Tabellen das Feld “deleted” enthalten und auch der Kickstarter legt dieses Feld standardmäßig an. Jeder Datensatz, der in TYPO3 gelöscht wird erhält in diesem Feld den Wert 1. Der Datensatz ist im Backend nicht mehr sichtbar, in der Datenbank aber noch vorhanden. Ich halte diesen Mechanismus für sehr hilfreich, gerade wenn es um wichtige Kundendaten geht.

Deshalb habe ich mich entschlossen, das Löschen über die exec->UPDATEquery Funktion zu realisieren, indem der Wert deleted auf 1 gesetzt wird. Ich erhalte mir so die Möglichkeit, Daten einfach wiederherzustellen.

Die Datenbank wird immer größer

Das ist sicherlich ein Einwand, aber TYPO3 verfährt ja grundsätzlich so, warum sollte man das für seine Eigentwicklung nicht übernehmen? Als letzte Verwaltungsinstanz setze ich daher kj_recycler ein. Diese Extension listet im Backend alle “gelöschten” Datensätze (deleted = 1) auf und bietet das endgültige Löschen an.

Ext: kj_recycler löscht TYPO3 Datensätze endgültig

Wie löst Ihr Aufgabenstellungen, die das Löschen von Daten in TYPO3 beinhalten? Ich bin gespannt auf eure Vorschläge!