Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Symfony's internals

88b8138397e1d1441f4e4a54348bde09?s=47 ubermuda
February 17, 2010

Symfony's internals

88b8138397e1d1441f4e4a54348bde09?s=128

ubermuda

February 17, 2010
Tweet

More Decks by ubermuda

Other Decks in Technology

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