About me
Zend Certified Engineer
Developer at Sensio Labs
Vice-President of AFSY (French Symfony User Group)
Co-author of "More with symfony"
As you can see, I love bermudas
http://twitter.com/ubermuda (mostly in french sorry)
Slide 3
Slide 3 text
More with symfony?
Yes, I wrote the Symfony Internals chapter
Don't worry if you read it already
There's new material here
Slide 4
Slide 4 text
Introduction
The symfony framework
Customizable
Flexible
Extensible
Slide 5
Slide 5 text
Customizable
Configuration files
settings.yml
factory.yml
Hierarchical configuration
Lots of ways to handle how the framework behaves
Slide 6
Slide 6 text
Flexible
The framework bows to your needs
Does not enforce an ORM
Does not enforce an user management system
Does not enforce a mailer
Etc.
Slide 7
Slide 7 text
Extensible
You can easily add capabilities
Using plugins
Hooking up on events
Overriding entire parts of the framework
Slide 8
Slide 8 text
How is it achieved?
Yes, how?
Slide 9
Slide 9 text
The bootstrap
Retrieves the application's configuration
Instanciates sfContext
Initiates dispatching
Slide 10
Slide 10 text
sfContext ?
Implements the Singleton design pattern
Has its pros and cons
Mostly, cons. (testability issues, etc)
Responsible for loading factories
(We'll talk about factories later)
Slide 11
Slide 11 text
The application configuration
frontendConfiguration
Extends ProjectConfiguration
Shares methods
Also, constructors
Most customization usually happens in ProjectConfiguration
Slide 12
Slide 12 text
The project configuration
Two very important steps:
Creates an event dispatcher
Loads plugins
Slide 13
Slide 13 text
The event dispatcher
sfEventDispatcher
Available as a separate component
http://components.symfony-project.org/event-dispatcher/
Implements the Observer pattern
Used throughout the whole framework
Slide 14
Slide 14 text
The event dispatcher
Available configuration events
autoload.filter_config
Allows to customize the autoloader configuration
More events later
Slide 15
Slide 15 text
Plugins
Used to extend the framework capabilities
Can contain entire modules
Or just hook on some event
Or provide a specific library
Etc.
Slide 16
Slide 16 text
Plugins
Have their own configuration file
used to be config/config.php
Now sfMyPluginConfiguration
extends sfPluginConfiguration
sfPluginConfigurationGeneric (if none was found)
Slide 17
Slide 17 text
Plugins
Find plugins
http://www.symfony-project.org/plugins/
http://www.symplist.net/
More than 900 plugins available!
Write your own plugins
It's easy
Simplifies code re-use
Slide 18
Slide 18 text
The configuration files
settings.yml
Holds the framework settings
And there are a lot of them
Actions, security strategies, I18N, debug bar, etc
http://www.symfony-project.org/reference/1_4/en/04-Settings
Slide 19
Slide 19 text
The configuration files
app.yml
Application specific configuration
You decide what's in there
Project wide app.yml (config/app.yml)
Slide 20
Slide 20 text
Environments
Environment specific configuration
Default envs are prod, dev and test
Configuration fine-tuning
Have a different database
Use a different mailing strategy
It's all handled by a ConfigHandler
Slide 21
Slide 21 text
Config Handler ?
Not very well known part of symfony
Parse and translate configuration files
Each configuration file has its own handler (kinda)
sfDefineEnvironmentConfigHandler
sfDatabaseConfigHandler
sfFactoryConfigHandler
Etc.
Slide 22
Slide 22 text
Back to sfContext
Instanciates factories
Components that drive your application
Logger, I18N, mailer, request, response, etc.
Configured through factories.yml
Has its own ConfigHandler too!
Slide 23
Slide 23 text
The factories configuration
Configured per-application
In your app's config/factory.yml
Gives you control over the whole framework
Handle by sfFactoryConfigHandler
Slide 24
Slide 24 text
sfFactoryConfigHandler
Translates your factory.yml into executable PHP
Slide 25
Slide 25 text
It's all in your cache
All config handlers use the config cache
Look in your cache/ directory for more information
Slide 26
Slide 26 text
The factories
You can override almost every components used by symfony
There is a reference for that, of course
http://www.symfony-project.org/reference/1_4/en/05-Factories
Slide 27
Slide 27 text
Here be events
Events notified during the factories loading
request.filter_parameters
routing.load_configuration
context.load_factories
Slide 28
Slide 28 text
context.load_factories
Earliest event where access to all factories is possible
Database access anyone?
Slide 29
Slide 29 text
The dispatch process
and more
Slide 30
Slide 30 text
The front controller
sfFrontWebController implements the Front Controller pattern
http://en.wikipedia.org/wiki/Front_Controller_pattern
Grabs module and action from the request
Issues a simple forward()
Slide 31
Slide 31 text
sfError404Exception
Thrown if no module/action was found
Will stop symfony's workflow
Forces a redirect to configured 404 handler
sf_error_404_module
sf_error_404_action
Can be thrown from anywhere in your application
Slide 32
Slide 32 text
The admin generator
Well-known symfony feature
generator.yml is consumed just there
Because we need the base action classes
By its own Config Handler, of course
http://www.symfony-project.org/reference/1_4/en/06-Admin-
Generator
Slide 33
Slide 33 text
sfGeneratorConfigHandler
Instanciates a generator
Runs it
There is no step 3
Slide 34
Slide 34 text
Controllers dir
You can't do much here
Except override getControllersDir()
Gives you huge control over the controllers' location
You can add any directory to the list
Or just plain replace it
Slide 35
Slide 35 text
The action stack
A FIFO (First In First Out) stack
Holds every action that were or will be executed
Access it through sfContext's getActionStack()
Useful to interact with the action (getActionName(), etc)
Slide 36
Slide 36 text
Enabling and disabling modules
Two ways of doing this
Through sf_enabled_modules, in settings.yml
Through mod_MyModule_enabled, in module.yml
The difference is how disabled modules are handled
Slide 37
Slide 37 text
Enabling and disabling modules
Modules disabled through settings.yml
Will cause a sfConfigurationException to be thrown
Should be used for permanently disabled modules
Slide 38
Slide 38 text
Enabling and disabling modules
Modules disabled through module.yml
Will redirect to the "disabled module" module
sf_module_disabled_module
sf_module_disabled_action
Should be used for temporarily disabled modules
Slide 39
Slide 39 text
The filter chain
and yet another design pattern
Slide 40
Slide 40 text
The filter chain
Implements the Chain of Responsibility pattern
http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern
Configurable through filters.yml
It has a Config Handler too (sfFilterConfigHandler) :-)
Slide 41
Slide 41 text
Default filters configuration
Slide 42
Slide 42 text
Write your own filters
Extend sfFilter
Everything happens in the execute() method
Slide 43
Slide 43 text
Adding your own filters
It's just a matter of adding it to the filters.yml
Between security and cache, that is
Also, keep the rendering filter on top of the stack
Slide 44
Slide 44 text
Adding your own filters
Slide 45
Slide 45 text
The rendering filter
Does nothing right now
Remember, a filter can execute code
Before the rest of the stack
But also after
Slide 46
Slide 46 text
The security filter
First filter to actually execute code
Runs a bunch of security checks
Configured through security.yml
Checks for unauthenticated requests
Or requests with insufficient credentials
Slide 47
Slide 47 text
Unauthenticated requests
Redirected to the "login" page
sf_login_module
sf_login_action
Slide 48
Slide 48 text
Insufficient credentials
Uses the "secure" page
sf_secure_module
sf_secure_action
Slide 49
Slide 49 text
The cache filter
Has two bits of logic
Can prevent the rest of the chain to execute
Not very likely, though
Configures the HTTP cache headers
Fills in the cache before rendering
Slide 50
Slide 50 text
The execution filter
Finally! Let's get some real work done
Checks for cache
If no cache is found, executes the action
Calls the view script
A word on the return value
Determines what view gets executed
You already know SUCCESS
You most certainly also know NONE
You might also know ERROR
But there are more builtin types (ALERT and INPUT)
You can actually return anything you want
Slide 53
Slide 53 text
Handling the view
This is sfView's job
Two ways of getting a view object
Custom sfView object for a specific action
Class name from mod_module_view_class
Default is sfPHPView
Slide 54
Slide 54 text
sfPHPView
Loads core and standard helpers
Helper, Url, Assets, Tag and Escaping
sf_standard_helpers, in settings.yml
Executes a view script (pure PHP)
Decorates the result
Also handles some caching
Slide 55
Slide 55 text
sfPartialView
Responsible for rendering partials and components
Has its own logic
Handles cache for partials and components
Slide 56
Slide 56 text
Custom view examples
sfTwigView
Integrates the Twig template engine
http://github.com/henrikbjorn/sfTwigPlugin
sfTemplatingView
Integrates templating from the symfony components
http://www.symfony-project.
org/plugins/sfTemplatingViewPlugin
Slide 57
Slide 57 text
The return of the rendering filter
Remember the rendering filter ?
Well it's back, and it wants to render.
Sends the response content through sfWebResponse's send
method
Slide 58
Slide 58 text
That's all folks!
We're now ready to handle one more request
Hopefuly faster than we just did ;-)
Slide 59
Slide 59 text
Thank you
Hope you learned stuff!
Read the book for a more detailed (and boring) approach
http://www.symfony-project.org/more-with-symfony/1_4/en/10-
Symfony-Internals