1. EVENT MANAGER

2. PUBLISHER - SUBSCRIBERS
• Made the code we had for behaviors, helpers, components,
etc. into a reusable generic events system
• Theidea is simple: an object publishes a named event with
some data and an unknown list of listeners will get notified
and have the chance of changing the outcome of the original
operation

3. SOME BUILT-IN EVENTS
• Model.beforeValidate,
Model.afterValidate,
Model.beforeSave, Model.afterSave...
• Controller.initialize,
Controller.startup,
Controller.beforeRender...
• View.beforeRender, View.beforeLayout...
• Dispatcher.beforeDispatch, Dispatcher.afterDispatch

4. CREATE YOUR OWN EVENTS!
•A Paypal plugin received a notification from payments server.
What do you do? (You need to send emails, mark order s
processed, decrement stock...)
• Trigger a new Paypal.afterProcess event!
• Any number of listeners can processes the rest of the actions
for you while leaving the Paypal plugin free of any external
concerns

5. A SIMPLE EXAMPLE

6. SUBSCRIPTION PATTERNS
• Direct: during
runtime an object attaches event listeners to
another as needed
• Configuration based: define a list or listeners. Read the list in
the publisher class or factory when needed
• Indirectglobal: Use the global event manager to attach
indirectly to any event.
• Conventionbased: load listeners for an object from a
convention-defined location

7. USING THE GLOBAL
MANAGER

8. DISPATCHER FILTERS
Let’s jump directly to examples :)

9. AN ASSET COMPRESSOR

10. A RESPONSE CACHER

11. SOME COOL IDEAS WITH
FILTERS
• Complete reverse proxy
• Pluggable OAuth Authorization
• Performance monitoring

12. HTTP CACHING

13. TYPES OF CACHE
• Browser caches
• Proxy caches
• Gateway caches (or reverse proxy)

14. HEADERS INVOLVED IN
CACHING
• Cache-Control - This it the most important one
• Expires
• ETag
• Last-Modified

15. MESSING WITH CACHE-
CONTROL
Proxies use shared cache, so setting a
response as private will not be cached by
default

16. VALIDATION VS EXPIRATION
• Expiration
model: you specify for how long a response is valid,
new requests will not be made until time expires
• Validation: requests
are made every time and server responds
with either a 304 status or a new response.

17. MESSING WITH EXPIRATION
Using max-age and s-maxage is preferred because of
several limitations in the Expire header

18. VALIDATION MODEL
If browser send If-Modified-Since header, then a 304
response will be issued and view rendering process will
be skipped entirely

19. CONDITIONAL VIEW RENDER
Same as previous example, but automatic and awesome

20. CACHE GROUPS

21. WHAT ARE THEY?
•A declarative, static way of tagging cache entries with any
string
• Entries
tagged with the same string can be invalidated all at
the same time in an atomic way
•A way to organize your cache entries into logical groups

22. A SIMPLE EXAMPLE

23. CACHE GROUPS FACTS
• Clearingall entries under a groups will delete all entries for all
Cache configurations having the same groups in them and
sharing the same prefix. Even across engines!
• Youcannot dynamically add new groups to cache
configurations, you need to plan your strategy
• You*could* dynamically create cache configs having exactly
the groups you want to tag entries with, but it’s super hard

24. MODEL VALIDATOR

25. WHAT FOR?
• Some applications require dynamic validations rules depending
on the action being executed
• Directly modifying $validate property on the model can be
tricky
• Severalparts of CakePHP had to implement the same
$validates parsing to extract information out of it

26. WHAT CAN I DO WITH IT?
• Dynamically inspect, add or remove validations rules for a
model
• Swap at runtime validation objects depending on your own
logic
• Create with an easy API complex validation systems

27. ADDING NEW RULES

28. MODIFYING RULES

29. DELETING RULES

30. USING ARRAY ACCESS