Talk presented during PHP Matsuri 2012 in Fukuoka, Japan about the planned features and changes for CakePHP 3.0

1. CakePHP 3.0
Embracing the future

2. About me
@jose_zap

3. I love scuba diving

4. And enjoy all
sorts of extreme
Like rock climbing

5. or rafting

6. and Sky diving

7. 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 (?)

8. 7 years ago...
CakePHP is released to the public to fix ALL THE THINGS

9. A pioneer in PHP land
MVC
Convention over configuration
Object oriented
Active record like database abstraction
Secure by default

10. Always innovating...
Unit testing 20
08
PHP implementation of multibyte extension
Command line php shells
Plugins!
Reverse routing
Behaviors, Form helper, pagination, caching, i18n and much
more

11. We made it flexible
20
10
Pluggable logging system
Caching, session and javascript engines
Localized validation
Routing with custom classes
Configurable paths

12. Even more flexible and reliable!
20
PHP 5.2 11
Customizable error handlers
Pluggable Auth component and email system
PHPUnit
PDO
Request and Response objects

13. Even more feature rich yet faster
20
View blocks 12
Content-type aware view classes
Easier HTTP caching
Configuration engines
Middleware (Dispatcher filters)
Generic events system

14. Coming soon..
20
12
CakePHP 2.3
PHP 5.4 local server
Better encryption strategies for authentication
Tons of small fixes that will just make you happier

15. 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

16. Time to go back to the future

17. Who needs PHP 5.3?
Let’s go with 5.4 all the way!

18. 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!

19. Adopt namespaces

20. We hate the wrong slash ()
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”

21. Configuration Changes

22. 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

23. Example bootstrap.php file

24. Example cache.php file

25. Improved and faster routing

26. 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

27. 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
AppControllerAdminUsersController::index()

28. Routing example

29. New database layer

30. 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

31. 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

32. Usable connection object

33. Custom data types

34. Query Object

35. 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

36. Record objects
Access record data
Provide getters and setters
Access associated model data
Save, delete and update themselves
Validation

37. Putting it all together

38. Using records

39. Undecided...
Model behaviors will be traits
Callbacks, some are table level others record level
Saving on associated objects

40. We need your help
to deliver faster