This document provides an overview of Symfony's internals. It discusses how Symfony initializes through the bootstrap, loads the configuration via the sfContext, and handles requests through the front controller and filter chain. It also covers how plugins, factories, and events extend Symfony's capabilities. Key components explained include the event dispatcher, configuration handlers, and different views that power Symfony's flexibility and extensibility.
2. 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)
3. More with symfony?
Yes, I wrote the Symfony Internals chapter
Don't worry if you read it already
There's new material here
10. 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)
13. 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
14. The event dispatcher
Available configuration events
autoload.filter_config
Allows to customize the autoloader configuration
More events later
15. Plugins
Used to extend the framework capabilities
Can contain entire modules
Or just hook on some event
Or provide a specific library
Etc.
16. Plugins
Have their own configuration file
used to be config/config.php
Now sfMyPluginConfiguration
extends sfPluginConfiguration
sfPluginConfigurationGeneric (if none was found)
17. 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
18. 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
19. The configuration files
app.yml
Application specific configuration
You decide what's in there
Project wide app.yml (config/app.yml)
20. 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
21. 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.
22. 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!
23. The factories configuration
Configured per-application
In your app's config/factory.yml
Gives you control over the whole framework
Handle by sfFactoryConfigHandler
25. It's all in your cache
All config handlers use the config cache
Look in your cache/ directory for more information
26. 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
27. Here be events
Events notified during the factories loading
request.filter_parameters
routing.load_configuration
context.load_factories
30. 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()
31. 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
32. 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
34. 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
35. 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)
36. 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
37. Enabling and disabling modules
Modules disabled through settings.yml
Will cause a sfConfigurationException to be thrown
Should be used for permanently disabled modules
38. 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
40. 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) :-)
42. Write your own filters
Extend sfFilter
Everything happens in the execute() method
43. 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
45. The rendering filter
Does nothing right now
Remember, a filter can execute code
Before the rest of the stack
But also after
46. 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
49. 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
50. 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
52. 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
53. 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
54. 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
56. 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
57. 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
58. That's all folks!
We're now ready to handle one more request
Hopefuly faster than we just did ;-)
59. 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