CakePHP 3.0Embracing the future

About me@jose_zap

I love scuba diving

And enjoy all sorts of extreme

Like rock climbing

or rafting

and Sky diving

7 years ago...

PHP 4.3 was king

PHP 5.1 was about to be released

There was no PDO, no json extension by default, no unicode and no SPL

Object orientation was very immature and buggy in PHP

No actual frameworks on the market, there was xoops and mojavi (?)

7 years ago...

CakePHP is released to the public to fix ALL THE THINGS

A pioneer in PHP land

MVC

Convention over configuration

Object oriented

Active record like database abstraction

Secure by default

Always innovating...

Unit testing

PHP implementation of multibyte extension

Command line php shells

Plugins!

Reverse routing

Behaviors, Form helper, pagination, caching, i18n and much more

2008

We made it flexible

Pluggable logging system

Caching, session and javascript engines

Localized validation

Routing with custom classes

Configurable paths

2010

Even more flexible and reliable!

PHP 5.2

Customizable error handlers

Pluggable Auth component and email system

PHPUnit

PDO

Request and Response objects

2011

Even more feature rich yet faster

View blocks

Content-type aware view classes

Easier HTTP caching

Configuration engines

Middleware (Dispatcher filters)

Generic events system

2012

Coming soon..

CakePHP 2.3

PHP 5.4 local server

Better encryption strategies for authentication

Tons of small fixes that will just make you happier

2012

An increasing debt...

Model layer is basically the same since PHP 4

No namespace support

Inflexible in some parts due to original PHP object restrictions

It could be faster

Sometimes encourages bad coding practices

Time to go back to the future

Who needs PHP 5.3?

Let’s go with 5.4 all the way!

PHP 5.4, what we’re after

Traits, they seem like a good way of implementing behaviors

Closure binding, an alternative way of injecting finders or more behaviors

JsonSerializable interface, easier web services

It’s faster!

Adopt namespaces

We will keep as much as possible our current way of addressing to class names (using conventions and dot notation)

Already prepared for this moment in 2.0, we are just replacing App::uses() with native “use” statements

Classes will keep their suffixes, for instances PostsController will still be named the same instead of just “Posts”

We hate the wrong slash (\)

Configuration Changes

More freedom and clarity for you

Unified configuration: No more Cache::config(), everything is setup in the Configure class now

Remove obscurity and still use conventions. Each step of the bootstrapping process will be handled in a separate file

Example bootstrap.php file

Example cache.php file

Improved and faster routing

Time to cut the fat

Named params are going to be removed (no more /var:value/)

Ability to set ssl, scheme, host and port in router calls

Named routes for faster lookups

Prefix routing to map subclasses

Constant reverse routing time

Prefixed actions

No more mixing admin and non admin actions in the same class

Prefixed routing will map to classes inside a namespace

Instead of UsersController::admin_index() you will have App\Controller\Admin\UsersController::index()

Routing example

New database layer

Current problems...

Frankenstein models. Is it a record or a table?

Inconsistent API. Model::read() vs. Model::find()

No Query object, only arrays

No Record object

Recursive and Containable should be kissed good bye

DboSource is dependent on the models and viceversa

A shiny new database layer

Clean separation of concerns: database layer should be usable on its own

Create a rich query builder

Intelligent data types. Cross database support for database data types (bigint, uuid, datetime, array, etc.)

Pluggable. Most aspect of this layer should swappable with custom classes

Usable connection object

Custom data types

Query Object

Table Objects

Will represent the database table/collection

Responsible for actually persisting, finding, deleting records

Schema can be declared and managed here

Can be optionally created (a default object is used instead)

Will be very similar to what current CakePHP models are now

Record objects

Access record data

Provide getters and setters

Access associated model data

Save, delete and update themselves

Validation

Putting it all together

Using records

Model behaviors will be traits

Callbacks, some are table level others record level

Saving on associated objects

Undecided...

We need your helpto deliver faster