Symfony Internals

Symfony Internals diving into symfony's guts

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)

More with symfony? Yes, I wrote the Symfony Internals chapter Don't worry if you read it already There's new material here

Introduction The symfony framework Customizable Flexible Extensible

Customizable Configuration files settings.yml factory.yml Hierarchical configuration Lots of ways to handle how the framework behaves

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.

Extensible You can easily add capabilities Using plugins Hooking up on events Overriding entire parts of the framework

How is it achieved? Yes, how?

The bootstrap Retrieves the application's configuration Instanciates sfContext Initiates dispatching

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)

The application configuration frontendConfiguration Extends ProjectConfiguration Shares methods Also, constructors Most customization usually happens in ProjectConfiguration

The project configuration Two very important steps: Creates an event dispatcher Loads plugins

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

The event dispatcher Available configuration events autoload.filter_config Allows to customize the autoloader configuration More events later

Plugins Used to extend the framework capabilities Can contain entire modules Or just hook on some event Or provide a specific library Etc.

Plugins Have their own configuration file used to be config/config.php Now sfMyPluginConfiguration extends sfPluginConfiguration sfPluginConfigurationGeneric (if none was found)

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

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

The configuration files app.yml Application specific configuration You decide what's in there Project wide app.yml (config/app.yml)

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

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.

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!

The factories configuration Configured per-application In your app's config/factory.yml Gives you control over the whole framework Handle by sfFactoryConfigHandler

sfFactoryConfigHandler Translates your factory.yml into executable PHP

It's all in your cache All config handlers use the config cache Look in your cache/ directory for more information

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

Here be events Events notified during the factories loading request.filter_parameters routing.load_configuration context.load_factories

context.load_factories Earliest event where access to all factories is possible Database access anyone?

The dispatch process and more

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()

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

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

sfGeneratorConfigHandler Instanciates a generator Runs it There is no step 3

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

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)

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

Enabling and disabling modules Modules disabled through settings.yml Will cause a sfConfigurationException to be thrown Should be used for permanently disabled modules

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

The filter chain and yet another design pattern

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) :-)

Default filters configuration

Write your own filters Extend sfFilter Everything happens in the execute() method

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

Adding your own filters

The rendering filter Does nothing right now Remember, a filter can execute code Before the rest of the stack But also after

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

Unauthenticated requests Redirected to the "login" page sf_login_module sf_login_action

Insufficient credentials Uses the "secure" page sf_secure_module sf_secure_action

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

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

The execution workflow Quite straightforward preExecute execute (via sfActions' execute()) postExecute

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

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

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

sfPartialView Responsible for rendering partials and components Has its own logic Handles cache for partials and components

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

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

That's all folks! We're now ready to handle one more request Hopefuly faster than we just did ;-)

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

Questions? speak slowly please

http://www.symfony-project.org	128
http://swik.net	121
http://symfony.com	109
http://www.slideshare.net	36
http://www.phphatesme.com	27
http://coderwall.com	4
http://pt.minichiello.name	4
http://webcache.googleusercontent.com	2
http://www.sfexception.com	2
http://www.brijj.com	1
http://www.linkedin.com	1

Symfony Internals

by Geoffrey Bachelet

Accessibility

Categories

Upload Details

Usage Rights

11 Embeds 435

Statistics

Symfony Internals Presentation Transcript