the works) Read check.php for details (dev/prod php.ini's from Liip) Using OSX? php53-intl from liangzhenjing or build-entropy-php from chregu Blog post on installing PHP 5.3 with intl from Justin Hileman Initial setup symfony-sandbox symfony-bootstrap Symfony2Project Read the Coding Style Guide (Code Sniffer Rules) Managing external dependencies Submodule: not everything is in git (svn, mercurial, etc.) Vendor install/update scripts: risk of getting out of sync MR (not cross platform)
Creates request (from globals) and passes to kernel 2. Kernel Loads app config (app/config/config_[prod|dev|test]) Resolves URL path to a controller (go to 3) Outputs response returned by the controller 3. Controller Loads model and view Potentially creates a sub-request (go to 2) Creates response and returns it
Readable service configurations Gotchas: Can become hard to work with if the DI extension tries to do too much Be aware of circular dependencies Might lead to code that cannot be used outside of DIC
YAML and PHP uses underscore to separate words XML uses dashes to separate words XML attributes usually map to array values in YAML/PHP YAML merge key syntax to reuse pieces within a file XSD-aware editors provide auto-completion/validation XML is recommended for Bundle/DI configuration YAML is recommended for application configuration Bundle extensions can optionally utilize the Config component to normalize/parse configurations in any format See FrameworkExtension, SecurityExtension, TwigExtension
must use container injection Create a Bundle extension to load Bundle services It's recommended to not extend from the base Controller The base controller is mainly a tool for beginners It provides convenience methods that invoke services, such as generateUrl(), redirect(), render()
one application for both frontend and admin backend Location of AppKernel is totally flexible, just update the frontend controllers accordingly Large projects should use multiple applications Better separation when multiple teams work Facilitate step-by-step updating and refactoring For example: main, mobile, API, admin
DB schema BC breaks Use DoctrineMigrationBundle app/console doctrine:migrations:diff app/console doctrine:migrations:migrate Do not use entities in migration scripts ever! Write fixtures as migrations or make the fixtures able to update existing data gracefully app/console doctrine:data:load --fixtures=app/fixtures
Side Includes (ESI) Proxy assembles page from snippets of HTML Snippets can have different cache rules Develop without ESI, test with Symfony2 internal ESI proxy, deploy using ultra-fast Varnish Proxy Break up page into different controller actions based on cache invalidation rules Do not worry about overhead from multiple render calls Never mix content that has different cache timeouts Consider caching user specific content in the client Varnish Reverse Proxy Super fast, PHP cannot match its performance Cache full pages for anonymous users Not just for HTML, also useful for JSON/XML API's
Write custom cache warmers Do not explicitly inject optional services to controllers If your controller receives many services, which are optional or unused by some actions, that's probably a hint that you should break it up into multiple controllers Do minimal work in the controller, let templates pull additional data as needed Use a bytecode cache with MapFileClassLoader
core classes have interfaces (easy mocking) No base classes, no static dependencies, no ActiveRecord Client fakes "real" requests for functional testing (BrowserKit component) Functional Testing Pros: tests configuration, tests API not implementation Unit Testing Pros: pinpoints issues, very directed testing http://www.slideshare.net/avalanche123/clean-code-5609451 Recommendation: Functional testing is recommended for controller actions Symfony2 provides WebTestCase and BrowserKit Unit testing for complex algorithms, third party API's too hard to mock Use Liip\FunctionalTesting to load fixtures, validate HTML5
in YAML Build Debian packages with MAKE Install with apt-get install Server specific settings are asked during install, change later with dpkg-reconfigure Maintain a global overview of all application dependencies in case of (security) updates Watch Lukas' unconference talk later today! Fabric (used at OpenSky) Repository managed with git-flow Clone tagged release branch, init submodules Fix permissions (e.g. cache, log), delete dev/test controllers Replace password/API-key placeholders with prod values in config files Upload in parallel to production nodes, swap "current" symlink
work on an existing Symfony2 bundle and never recreate my own. #focus #teamwork @weaverryan Ryan Weaver 27 Dec http://twitter.com/weaverryan/status/19565706752299009
(http://github.com/friendsofsymfony) UserBundle (forked from knplabs' DoctrineUserBundle) FacebookBundle (forked from kriswallsmith) Liip (http://github.com/liip) FunctionalTestBundle ViewBundle OpenSky (http://github.com/opensky) LdapBundle Sonata (http://github.com/sonata-project) AdminBundle Additionally, a couple sites currently index community bundles: http://symfony2bundles.org/ http://symfohub.com/
version-tagging or official package manager (yet) Use bundles by adding git submodules to your project Maintain your own fork and "own" what you use Not all bundles are equally maintained Symfony2 API changes => broken bundles If you track symfony/symfony, learn to migrate bundles Avoid rewriting a bundle's services/parameters directly The bundle's DI extension should allow for such configuration; if not, submit a pull request If absolutely necessary, a CompilerPass is cleaner
guidlines Fork and add remote repository Merge regularly to keep up-to-date Avoid committing directly to your master Merges from upstream should be fast-forwards Once upstream changes are stable, bump your project's submodule pointer
new features Can't wait to use this in your project? Temporarily change your project submodule to point to your branch until your pull request is accepted. Help ensure that your pull request merges cleanly Create feature branch based on upstream's master Rebase or merge upstream's master when finished
Congratulations! Don't merge your feature branch into master! Doing so would cause your master to divert Merge upstream's master into your master Delete your feature branch Update your project's submodule to point to master
html If you are still fuzzy on Dependency Injection: http://fabien.potencier.org/article/11/what-is-dependency-injection If you keep up with Symfony2 repository on github: http://docs.symfony-reloaded.org/master/
ways: Using the "new" operator Using an object factory All objects get collaborators in one of two ways Passed to object constructor Set using a setter