The road to TYPO3 5.0 Phoenix

Gimme Five!The road to TYPO3 5.0 „Phoenix“

Phoenix

Phoenix

Overview

Starting point: Why we need TYPO3 5.0

Beyond the horizon: Objectives of the project

Project status: What has happened so far

A flexible foundation: The content repository

The road to Phoenix: An initial roadmap

Why we need TYPO3 5.0

Some reasons for 5.0 ...

Complexity - the TYPO3 core architecture reached its limit and takes quite some time to learn

Data model – the current approach is not flexible enough and direct database access (even through DBAL) causes problems

PHP5 – the new features of PHP5 allow for a much cleaner and developer-friendly architecture

Connectivity – a future architecture will provide much better support for external access (SOAP, WebDAV, 3rd party tools)

Some more reasons for 5.0 ...

In the mid term TYPO3 will have about 10.000 extensions - of varying quality in terms of code and security

In large-scale enterprises and medium-sized businesses TYPO3 is increasingly used in critical areas

The developer teams will grow and require a more modular and accessible software

New CMS projects can use new technologies irrespective of legacy – why shouldn‘t we?

Objectives of the project

Core objectives

Creation of a clean code base

Protection of TYPO3‘s „soul“

Modularity and abstraction of the core functions

Flexible and scalable architecture

Use of standards and established techniques

Ease of use on all levels

Realistic migration path

Challenge: architecture

Layered architecture: pretty easy

pretty: lowest level meets highest aesthetic requirements

easy: highest level is easy to use - even for PHP rookies

Built-in security (examples):

data access through objects

Cross-site-scripting and SQL injection is not possible

Upfront recycle design with radical refactoring

Migration and acceptance

Development of TYPO3 4.x and 5.x continues in parallel

Protection of investment into knowledge and development

Early integration of the community

Easy migration of important components

Well-proven concepts are preserved

Impact roadmap

Core objective “Ease of use “:

What has happened so far

Initial ideas

Decision for creating a version 5.0 with a new architecture has been taken at the R&D committee meeting in May 2005

First R&D meeting specifically about 5.0 took place in December 2005

Final R&D meeting with brainstorming sessions in June 2006

Project start

Official start at the TYPO3 Developer Days 2006 in Dietikon / Switzerland

Brainstorming sessions had the same results as previous sessions and most of the discussions in the mailing lists

A project website and a mailing list for general discussion has been created

Karsten and Robert have (almost) weekly meetings for planning the 5.0 project

Teams and contribution

Foster diversity and innovation by different teams

Have your own mind – do research, create sketches, play with code

Create your own stand on the bazar

A new architecture

Tabula rasa

TYPO3 5.0 development starts from scratch

Improved Coding Guidelines and Coding Style Guide with glossary

Some base components are designed and implemented, then other components are shaped and filled with code from the 4.x branch

Components

Virtually any part of TYPO3 can be replaced by a new component providing the same API

Components have sub (-sub, ...) components

Each component has a well-defined interface. Encapsulation is enforced

Frontend plugins and backend modules are components, too. They just fall into a certain category

Component examples

The content repository

Current situation: RDBMS via DBAL

Trees are stored in different tables

Data is stored in table fields

Adding properties means adding fields to the table structure

Nested records are stored as XML in one table field

Records can be queried via SQL

Abstraction on query-level (no transactions, procedures etc.)

Not all data is stored in the database but in files

Flexible data structuresin TYPO3 4.x

The data structure of tt_content is fixed

The flexible data structure is stored as XML in one field:

Flexible data structuresin TYPO3 4.x

The data structure of tt_content is fixed

The flexible data structure is stored as XML in one field:

BAD!

B-Trees and other plants

B-Trees and other plants

B-Trees and other plants

B-Trees and other plants

TYPO3 CR: ODBMS

A CR is a kind of object database for storing hierarchical data

On top of a regular data source (MySQL, Oracle, CSV, Excel ...)

Trees are stored as nodes, data natively as properties

Nested „records“ are just stored as sub nodes

Data can be queried through SQL and XPATH

All storage and retrieval of data is handled through objects

All content (even files) is stored in the content repository

Advantages of a Content Repository

Flexible and extensible data structure

eg. data structures of TemplaVoilá‘s Flexible Content Elements are stored directly in the repository and can be queried

Object based storage and retrieval

Combines all advantages of navigational and relational databases

Security can be enforced on a higher level

Cleaner and easier to use for the developer

Advantages of a Content Repository

Data source abstraction instead of database abstraction

Data can be stored in different ways, a database is only one of them

Due to the higher level of abstraction, database specific functions and specialties like transactions, stored procedures, partitioning ... can be used on the CR implementation level

Speed

Depending on the CR implementation the speed gain for read access to the content tree can be immense

JSR-170

Java Specification Request N° 170

Specifies a standard API to access content repositories in Java independent of the implementation

JCR implementations:

DAY CRX (reference implementation)

Jackrabbit (open source)

JSR-170 and TYPO3 ?

In TYPO3 5.0 we want a content repository based on generic nodes and properties

JSR-170 defines a full featured API to access such a repository, including

Session handling

Transactions

Workspaces

Why reinvent the wheel?

JSR-170 and TYPO3 ?

The Java bridge allows us to access a Jackrabbit repository from PHP – that‘s a temporary shortcut!

TYPO3 5.0 will still run completely without Java - by accessing the PHP-based TYPO3 CR, based on the APIs defined in JSR-170

The goal: A flexible and powerful content repository for TYPO3 written in PHP 5

TYPO3 CR uses the JSR-170 interfaces where possible

Maybe only 98% of the standard will be implemented

An initial roadmap

Inital Roadmap http://typo3.org/teams/5.0-development/roadmap/

Inital Roadmap http://typo3.org/teams/5.0-development/roadmap/

Milestone one: Raw content access

Milestone two: Users, Rights and Localization / Translation

Milestone three: Rebirth of the frontend

Milestone four: Rebirth of the backend

Preview 1: Migration of backend extensions starts

Preview 2: Migration of frontend extensions starts

Links & resources

TYPO3 5.0 Development Team:http://typo3.org/gimmefive

These slides and other resources:http://typo3.org/teams/5.0-development/resources/

The initial roadmaphttp://typo3.org/teams/5.0-development/roadmap/

The TYPO3 Association Paypal accountpaypal@typo3.org

Gimme Five!The road to TYPO3 5.0 „Phoenix“

Gimme Five!Inspiring People To Share