Warum ich Boilerplates doof finde

Ich integriere seit ca. 2005 webites im TYPO3. Wenn man so lange dabei ist, gibt es einige Fragestellungen die sich immer wiederholen.
Eine der meist gestellten Fragen ist: Was ist in eurem Standard-Package? Habt ihr ein Agentur-Package? Was verwendet ihr als Boilerplate?

Ich muss gestehen, dass ich die Idee eines Boilerplate Packages über viele Jahre wirklich gut fand. Komischerweise habe ich es aber nie geschafft, ein eigenes Package zu schnüren und meine wenigen Ansätze habe ich es nie annähernd zur Produktreife geschafft.
Mein jüngster Versuch ist derzeit in auf github zu bestaunen, aber ich Achtung, es ist nicht fertig und das enthaltene typoscript ist nur für speziellen Seitentypen.

Nichts desto trotz bin ich der jüngsten Aufforderung eines Kollegen nachgekommen und habe, mit Blick auf das neueste Projekt und den Herausforderungen der letzten Projekte versucht, Code zu erzeugen, der eine Hilfe und kein Ärgernis ist.
Ich habe nach 3 Stunden kapituliert.

Ich habe mit TYPO3 Version 3.6 angefangen.
Seit diese Zeit haben sich so viele Dinge geändert und ein Package, eine Agenturextension oder ein Boilerplate muss zwangsläufig bei jeder neuen Version mitwachsen..
Leider fehlt mir die Zeit und vor allem die Lust irgendwelche verrückten, vielleicht coolen, Funktionen immer und immer wieder zu aktualisieren und im schlimmsten Fall für verschiedene Version bereit zu stellen.
Wahrscheinlich kennen die meisten von uns TYPO3 Installationen die nicht aktualisiert werden können weil die Super-Fancy-mit-so-vielen-Funktionen-Extensions nicht auf den aktuellen Stand gebracht werden (können).
Mein Ansatz ist das eher pragmatisch:
Wenn ich die Super-Funktion aus dem letzten Projekt brauche, ist es in der Regel viel schneller sie mit Copy&Paste zu übertragen.
Vor allem, weil die coole Super-Funktion meist noch eine Anpassung braucht.

Butter bei die Fische

Ein TYPO3-Projekt zu kickstarten dauert 30 Minuten. Ein Seitenbaum, Header- und Footernavigation sollten in weiteren 3 Stunden integriert sein (Wenn das Frontend fertig ist)
Ein Profilkarte mit Foto und Text braucht - nunja, das ist projektabhängig. Besteht die Karte aus Freitext? Kommen die Daten aus tt_address? Brauchen wir eine eigene Extension? Gegen wie viel Boilerplatecode muss ich ankämpfen um das Design zu integrieren?
Ein Boilerplate soll uns doch helfen - aber wo denn?
Eine Navigation besteht 8 Zeilen typoscript + Fluid-Template mit custom HTML.
OK - 8 Zeilen für das Boilerplate. (habe ich schon Copy&Paste erwähnt?)
Die Problem ist doch: Was brauchen wir um schnell ein Design zu integrieren und damit live gehen?

know your tools!

Die liebste aller Rückmeldungen ist mir: "Wenn ich das Projekt starte, bekomme ich einen Fehler".
Leute, sowas muss nicht sein. Mit 20+ Jahren sollte das mit dem Klopapier keine Frage mehr sein ...
Im Ernst. Wir sind Webentwickler! Wir machen das Internet! Die Basics müssen doch sitzen.
Und wenn nicht, dann in die Abendschule, nachsitzen! Und nicht sagen: Meine Chef gibt mir keine Zeit dazu. (Es sei denn, Du bist noch in der Ausbildung.)
Also das Motto heißt: Find it - Fix it.
Weitere Polemik erspare ich mir hier ...

Eine wirklich schnelle Entwicklungsumgebung

Die andere Seite ist eine wirklich schnelle Entwicklungsumgebung. Also ein Setup, welches die Entwicklung beschleunigt.
Tools welche mir turn-around Zeiten verkürzen oder abnehmen.

Und vor allem eine Werkezeugkiste, die die Lücke zwischen Frontend und Integration schließt.

Hier wird wirklich Zeit verbrannt!

Zuerst setzt der Frontend-Entwickler ein Design in HTML um. Hier kommen dann Template-Engines wie pug/jade oder Handlebar/Mustache zum Einsatz.
Zuerst wird ein immenser Aufwand getrieben um möglichst authentischen Content oder Ajax-Zugriffe zu simulieren.
Die Integration erfolgt dann, indem die vorhanden Quellen oder Kompilate zerteilt werden und in Fluid integriert werden.
Javascript und CSS werden als Kompilat direkt in das sitepackage kopiert.

Und jetzt fängt es an zu knirschen. Der Backend-Entwickler ändern, aus Gründen die nur ihm bekannt sind, einen Endpunkt für einen Ajax-Zugriff.
Das muss zurück an die Frontend-Abteilung adressiert werden, dort wird im Frontend die Simulation angepasst und der Integrator portiert die Änderung (per Copy&Paste) in das TYPO3.

Ja klar - wie sonst, sagen hier viele Entwickler.

Was für ein Unsinn.

Warum arbeiten nicht alle Kompetenzen zusammen und ineinander Verzahnt?
Warum kann ein Frontend-Entwickler nicht ein klein bisschen über seinen Tellerrand hinausschauen und sich überlegen ob eine HTML-Struktur überhaupt in einem CMS umsetzbar ist?
Warum kann ein Integrator oder Backend-Entwickler nicht 8 Zeile Javascript schreiben um einen Ajax-Zugriff zu implementieren?
Und überhaupt warum muss zu Integration so viel, nicht nachvollziehbares Copy&Paste gemacht werden?

Wie wäre es mit einer Entwicklungsumgebung in der Frontend, Integrator und Backend gemeinsam arbeiten? So richtig zusammen, als Team! Und wenn der Integrator den Code vom Backend sieht, hat er vielleicht mal einen guten Tipp fürs Frontend.
Oder der Backend-Entwickler lernt, so nebenbei, wie man einen schönen Ajax-Zugriff macht.

standalone oder fluid

Mit t3-build ist es möglich entweder mit einer kleinen Template-Engine in komplettes Frontend als standalone Version zu programmieren.
Der Integrator verwenden dann genau die gleichen Dateien und entwickelt sie weiter in fluid-Template.
Alternativ ist es auf auch möglich, den Standalone-Schritt zu überspringen und TYPO3 als Template Engine und Content Quelle zu verwenden.

Alle haben direkten Zugriff auf die echten Quellen

Da alle beteiligten Entwickler im gleichen Repository entwickeln und den gleichen Build-Prozess verwenden, kann jeder die Quellen des anderen einsehen und gegebenenfalls optimieren.

Schnellere Anpassung, Korrekturen und Weiterentwicklungen

Das ist so ein ganz toller Fall. Der Kunde sagt: "Bitte mach hier den Abstand größer"
Durchschnittliche Umsetzung: 5 Tage!
Durchschnittliche Anpassung: 2 Zeilen!
Wenn der Kunde Pech ist, ist der Frontend-Entwickler gerade im Urlaub.
Oder der Integrator. Dann kann der Kunde vielleicht einen Screenshot haben, aber live geht das noch lange nicht.
Das ist wirklich uncool. Deshalb bietet t3-build einen build-Prozess der in allen Stufen bis hin zum Deployment angewendet werden kann.
 

Für alle ungeduldigen:

Check it out

Leider hatte ich noch nicht die Kapazität die Doku auf den neuesten Stand zu bringen.

Das aktuelle Release hat zwei proprietäre Tags: standalone, fluid - Damit kann man Inhalte wrappen

Für alle anderen:

Stay tuned  - hier und im oben genannten Projekt werden noch mehr Infos kommen.