Symfony's internals

Transcript

1. Symfony Internals diving into symfony's guts
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
4. Introduction The symfony framework Customizable Flexible Extensible
5. Customizable Configuration files settings.yml factory.yml Hierarchical configuration Lots of ways to handle how the framework behaves
6. 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.
7. Extensible You can easily add capabilities Using plugins Hooking up on events Overriding entire parts of the framework
8. How is it achieved? Yes, how?
9. The bootstrap Retrieves the application's configuration Instanciates sfContext Initiates dispatching
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)
11. The application configuration frontendConfiguration Extends ProjectConfiguration Shares methods Also, constructors Most customization usually happens in ProjectConfiguration
12. The project configuration Two very important steps: Creates an event dispatcher Loads plugins
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
24. sfFactoryConfigHandler Translates your factory.yml into executable PHP
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
28. context.load_factories Earliest event where access to all factories is possible Database access anyone?
29. The dispatch process and more
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
33. sfGeneratorConfigHandler Instanciates a generator Runs it There is no step 3
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
39. The filter chain and yet another design pattern
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) :-)
41. Default filters configuration
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
44. Adding your own filters
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
47. Unauthenticated requests Redirected to the "login" page sf_login_module sf_login_action
48. Insufficient credentials Uses the "secure" page sf_secure_module sf_secure_action
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
51. The execution workflow Quite straightforward preExecute execute (via sfActions' execute()) postExecute
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
55. sfPartialView Responsible for rendering partials and components Has its own logic Handles cache for partials and components
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
60. Questions? speak slowly please