1. TYPO3 5.0
der aktuelle Stand der Zukunft
Jochen Rau <jochen.rau@typoplanet.de>
Mit Beiträgen von Robert Lemke und Sebastian Kurfürst
Hohenheim, 15. Mai 2009
2. Wer ist das?
Dipl.-Ing. Maschinenbau (Universität Stuttgart)
Erstinfektion mit TYPO3 im Jahr 2001 (danach 5 Jahre lang
immun)
lebe und arbeite heute in Tübingen
zu 60% selbständiger TYPO3-Entwickler
zu 60% Familienvater
Projektleiter für Extbase, dem neuen Framework für Extensions
ab TYPO3 v4.3
zuvor
5 Jahre wissenschaftlicher Mitarbeiter bei der Fraunhofer-Gesellschaft und
dem Deutschen Zentrum für Luft- und Raumfahrt
5 Jahre Oberstufenlehrer für Mathematik, Physik und Informatik
3. TYPO3 heute
erste Veröffentlichung 1998
33 Kernentwickler
bisher 500.000 Zeilen Code committed
aktuelle Codebase: 300.000 Zeilen
aktuelle stabile Version: TYPO3 4.2.6
60.000 bis 80.000 Downloads pro Monat
mehr als 30.000 Nutzer auf typo3.org registriert
höchste Verbreitung im Mittelstand, jedoch auch Nutzung
in großen Firmen und Organisationen: Dassault Systems,
3M, Sixt, Unesco, Unicef, WWF
4. TYPO3 heute
TYPO3 v4 ist nahezu vollständig ausgereift
letzte Releases: Fokus auf Usability-Verbesserungen für
Benutzer
gewachsene Architektur
kaum Unit-Tests
inkonsistente API
keine durchgehend objektorientierte Programmierung
große Änderungen sind risikoreich bis unmöglich
keine klare Trennung zwischen Applikations-Framework
und Content-Management-System
5. Warum TYPO3 v5.0?
Komplexität – Die Architektur des TYPO3 Core hat sein
Limit erreich und benötigt viel Einarbeitungszeit
Datenmodell – Der derzeitige Ansatz ist nicht flexibel
genug und bereitet bei direktem Datenbankzugriff
Probleme (auch mit DBAL)
PHP5 – Die neuen Möglichkeiten von PHP5.3 erlauben eine
viel sauberere Architektur
Schnittstellen – Eine neue Architektur ermöglicht eine
bessere Zusammenarbeit mit externen Diensten (SOAP,
WebDAV, 3rd party tools)
6. Warum TYPO3 v5.0?
Auf mittlere Sicht werden an die 5.000 Extensions für
TYPO3 4.x verfügbar sein - in sehr unterschiedlicher
Qualität
TYPO3 wird verstärkt in sicherheitskritischen Bereichen
großer und mittlerer Unternehmen eingesetzt
Die Entwicklung für TYPO3 wird mehr und mehr
professionalisiert (größere Teams mit mehr
Aufgabenteilung)
Neue CMS auf dem Markt können neue Technologien ohne
Rücksicht auf bestehenden Code nutzen
7. quot;Wir brauchen
ein neues
Framework!quot;
http://www.sxc.hu/photo/585791
11. TYPO3 v5.0
Was bleibt?
Es wird ein Back-End geben
TypoScript wird in einer neuen objektorientierten Version 2.0
veröffentlicht
Die Seitenbaum-Metapher bleibt erhalten
Was kommt
Klare Trennung von Zuständigkeiten durch entkoppelte Schichten
Wiederverwendbare Komponenten
Die Speicherung des Contents wird transparent für das CMS
Vollständige Abstraktion von einer Speicherlösung
Security wird zentralisiert
17. Domain-Driven Design
Domäne = Aktivität oder Geschäft des Benutzers
Fokus auf die Domäne, und die Logik der Domäne
genaue Abbildung der Sprache und der Regeln innerhalb
der Domänen auf Software
universelle Sprache („ubiquitous language“) zwischen den
Projektmitgliedern
die selben Wörter für Diskussion, Modellierung,
Entwicklung und Dokumentation
21. Model-View-Controller Pattern
1 2
BlogExample
Request
Dispatcher
TYPO3
HTML
Response Controller
6
3 assign(Blog)
5
render()
findByName('MyBlog')
Blog
Response
4 View
Repository
Domain Model
Blog
Post
Comment Tag
22. Transparente Persistenz
Ein Persistence-Manager verwaltet alle Objekte
Transparent für den Programmierer
Alle Domain-Aggregates, die durch ein Repository verwaltet werden,
werden automatisch persistiert
Änderungen an den Daten eines Objektes werden ebenfalls
automatisch persistiert
25. How to protect?
Es soll alles geschützt werden können
Das Grundlegendste, was geschützt werden kann sind
(PHP-)Funktionen und Methoden
Jemand muss entscheiden, ob eine Methode im aktuellen
Kontext aufgerufen werden darf
Jeder Methodenaufruf wird per AOP abgefangen ohne das
dies im original Code sichtbar ist (“touchless”)
Zentralisierte Sicherheit: Rollen und Priviliegien werden in
Access Control Lists (ACLs) definiert
26. The security election – voting for access
Die Entscheidung über den Zugriff liegt bei sog. Access
Decision Voters
Zugriff wird nur gewährt, falls mindestens ein “grant vote”
und kein “deny vote” vorliegt
Eigene Voter können implementiert werden
Ein Voter kann sich der Stimme enthalten, falls er nicht für
die aktuelle Methode zuständig ist
27. Argument-Validierung
Alle Argumente, die an den Action-Controller übergeben
werden, werden automatisch validiert
White-Lists: Nur registrierte Argumente sind verfügbar
Der Zugriff auf die $_GET- und $_POST-Variablen wird
abgefangen
28. Argument-Validierung
FLOW3 wird mit einer stattlichen Anzahl von Validatoren
ausgeliefert:
AlphaNumeric, EmailAddress, Float, Integer, NotEmpty,
Number, NumberRange, RegularExpression, UUID, Text
Eigene Validatoren können einfach erstellt werden
Validatoren können verkettet und verschachtelt werden
29. Definition der Validierungsregeln
Alle Validierungsregeln werden an Ort und Stelle durch
Kommentare festgelegt
Zusätzliche Regeln können aufgenommen werden
class Blog {
/**
* The blog's name. Also acts as the identifyer.
*
* @var string
* @validate Alphanumeric, Length(minimum = 3, maximum = 50)
* @identity
*/
protected $name = '';
/**
* A short description of the blog
*
* @var string
* @validate Text, Length(maximum = 150)
*/
protected $description = '';
30. Definition der Validierungsregeln
/**
* Create action for this controller.
*
* @param string $author
* @param string $emailAddress
* @param F3BlogDomainModelBlog $blog
* @return string The rendered view
* @validate $emailAddress EmailAddress
*/
public function createAction($author, $emailAddress, F3BlogDomainModelBlog $blog) {
[...]
}
31. Application Firewall
Die erste Verteidigungslinie
Blockiert Bad-Requests so früh wie möglich
Innerhalb der Firewall kann ein Request anhand von
Mustern klassifiziert werden (z.B. URL, IP address/range, ...)
Falls ein Muster passt wird der zugehörige Interceptor
aufgerufen (deny access, grant access, authentication
required, ...)
Falls kein Muster passt wird der Request standardmäßig
abgewiesen
33. Managed Objects
Der Lebenszyklus eines Objekts und das Zusammenspiel
der aktiven Objekte wird durch den Object-Manager
gesteuert
Das Verhalten der Objekte ist in FLOW3 frei konfigurierbar
34. Playing with building blocks
Je weniger eine Klasse von einer anderen Klasse weiß, desto
einfacher ist deren Wiederverwendung in verschiedenen
Kontexten
Gestalten Sie ihren eigenen LEGO-Baukasten, indem Sie
voneinander klar getrennte und entkoppelte Klassen
schreiben
35. Class Dependencies
Eine Klasse kommt selten alleine
Klassen hänge von anderen Klassen ab, diese hängen von
anderen Klassen ab, diese hängen von anderen ...
Problem: Klassen verweisen explizit auf andere Klassen
$phoneBookManager = new PhoneBookManager
36. Dependency Injection
In FLOW3 fragt eine Klasse nicht nach einer Instanz einer
anderen Klasse; sie bekommt diese automatisch injiziert
Das ist bekannt als das
quot;Hollywood Principlequot;:
quot;Don't call us, we'll call youquot;
Ermöglicht eine lose Kopplung
Verbessert den Programmierstil
Vorraussetzung für Unit Tests
37. Konstruktor ohne Dependency-Injection
/**
* @var F3MyPackageModelCustomerRepository
*/
protected $customerRepository;
/**
* Constructor
*
* @author Robert Lemke <robert@typo3.org>
*/
public function __construct() {
$this->customerRepository = F3MyPackageModel
CustomerRepository::getInstance();
}
38. Klasse mit Constructor-Injection
/**
* @var F3MyPackageModelCustomerRepository
*/
protected $customerRepository;
/**
* Constructor
*
* @author Robert Lemke <robert@typo3.org>
*/
public function __construct(F3MyPackageModelCustomerRepository
$customerRepository) {
$this->customerRepository = $customerRepository;
}
39. Klasse mit Setter-Injection
/**
* @var F3MyPackageModelCustomerRepository
*/
protected $customerRepository;
/**
* Injects the customer repository
*
* @author Robert Lemke <robert@typo3.org>
*/
public function injectCustomerRepository(F3MyPackageModelCustomerRepository
$customerRepository) {
$this->customerRepository = $customerRepository;
}
44. Cross-cutting concerns
Domain Model Domain Model Domain Model
CONCER
NS
Security
X-ING
Logging
45. Fehlende Funktionalität in PHP
Mit AOP kann man
alle „cross-cutting concerns“ zentralisieren und sauber
separieren
beliebige Methodenaufrufe abfangen
neue Funktionalität zu Code hinzufügen, ohne diesen zu
verändern
... viele weitere Tricks anwenden
46. Exkurs: Das Security-Framework
$customer->setName(...)
Presentation changeCustomerAction
Security Framework
Domain Customer
Data source
47. Exkurs: Das Security-Framework
$customer->setName(...)
Presentation changeCustomerAction
Security Framework
Domain Customer
Data source
Touchless Security!
49. Test Driven Development ...
... means that you write an automated
test, then you write just enough code to
make that one test pass, then you
refactor the code primarily to improve
readability and remove duplication.
Henrik Kniberg
55. Was ist eine Template-Engine?
übernimmt die Darstellung von Daten
lebt in der View-Komponente
Bekannte Engines
Smarty
*TAL
Velocity
Designer schreiben kein PHP, sondern HTML
56. Ziele für Fluid
einfache, elegante Template-Engine
vielfältige Unterstützung für den Template-Schreiber (z. B.
Autocompletion)
einfache und saubere Erweiterbarkeit durch Trennung in
Core-Komponenten und View-Helper
vielerlei Ausgabemedien möglich
57. Grundkonzepte von Fluid
Ausgabelogik ist in View Helpers (Tags) gekapselt
Namespace-
Beispiel Deklaration
{namespace f3=F3FluidViewHelpers}
<f:linkaction=“someAction“>more</f:link>
Aufruf eines
View Helpers
58. Grundkonzepte von Fluid
Jeder Tag entspricht einer Klasse
1. Beispiel
{namespace f=F3FluidViewHelpers}
<f:link>...</f:link>
F3FluidViewHelpersLinkViewHelper
2. Beispiel
{namespace f=F3FluidViewHelpers}
<f:form.textbox />
59. Grundkonzepte von Fluid
Variablen
$this->view->assign(‘blogTitle’,
$blog->getTitle());
<h1>Der Name des Blogs ist: {blogTitle}</h1>
60. Grundkonzepte von Fluid
Object Accessors
$this->view->assign(‘blog’, $blog);
<h1>Der Name des Blogs ist: {blog.title}</h1>
<p>Autor: {blog.author}</p>
Getter / Setter werden automatisch aufgerufen
67. Nächste Schritte
erste FLOW3-Beta in 3 Monaten
erste Pilotprojekte schon jetzt
Weiterentwicklung des CMS
Geplanter Beta-Release von TYPO3 5.0: Anfang 2010
68.
69. The Berlin Manifesto
We, the participants of the T3TD08 state that ...
TYPO3 v4 continues to be actively developed
v4 development will continue after the the release of v5
Future releases of v4 will see its features converge with those in
TYPO3 v5
TYPO3 v5 will be the successor to TYPO3 v4
Migration of content from TYPO3 v4 to TYPO3 v5 will be easily
possible
TYPO3 v5 will introduce many new concepts and ideas.
Learning never stops and we'll help with adequate resources to
ensure a smooth transition.
70. Patrick Broens, Karsten Dambekalns, Dmitry
Dulepov, Andreas Förthner, Oliver Hader,
Martin Herr, Christian Jul Jensen, Thorsten
Kahler, Steffen Kamper, Christian Kuhn,
Sebastian Kurfürst, Martin Kutschker, Robert
Lemke, Tobias Liebig, Benjamin Mack, Peter
Niederlag, Jochen Rau, Ingo Renner, Ingmar
Schlecht, Jeff Segars, Michael Stucki, Bastian
Waidelich
71.
72. Extbase — Das neue Framework für Extensions
quot;Nachfolgerquot; von tslib_pibase
Ausgewählte Komponenten und Paradigmen von FLOW3
wurden auf TYPO3 Version 4.3 portiert
Transparente Persistenz des Domain-Models
Model-View-Controller
Validierung
Ziele
Schon jetzt mit „FLOW3-Paradigmen“ programmieren
Migration des Codes vereinfachen
Lernpfad zu TYPO3 v5 eröffnen
74. Kickstarter für Extensions
Nachfolger für den bisherigen Kickstarter
Release geplant für Juli 2009
basiert auf den Prinzipien des Domain-Driven Design
Projekt des Google Summer of Code 2009
75. Fluid — Die Template-Engine für FLOW3 und v4.x
Fluid steht ab der Version 4.3 zur Verfügung
automatische Portierung des Kerns von Fluid
an TYPO3 v4 angepasste Tags und View-Helper
Standard Template-Engine für Extbase