STANDArDISATION

SYMFONY2 - KRUNO KNEGO - LOCASTIC

SF2 NAMING CONVEnTIONS

  • get()
  • set()
  • has()
  • all()
  • replace()
  • remove()
  • clear()
  • isEmpty()
  • add()
  • register()
  • count()
  • keys()

SF2 NAMING CONVEnTIONS

  • get()
  • set()
  • has()
  • all()
  • replace()
  • remove()
  • clear()
  • isEmpty()
  • add()
  • register()
  • count()
  • keys()
  • CookieJar has many Cookie objects
  • Service Container has many services and parameters
  • Input has many arguments and many options

SF2 NAMING CONVEnTIONS

  • CookieJar has many Cookie objects
  • Service Container has many services and parameters
  • Input has many arguments and many options

SF2 CODING STANDARDS

  • PSR-0
  • PSR-1
  • PSR-2

SF2 CODING STANDARDS

  • PSR-0
  • PSR-1
  • PSR-2

PHP STANDARDS RECOMMENDATION

SF2 CODING STANDARDS

  • PSR-0
  • PSR-1
  • PSR-2

PHP STANDARDS RECOMMNEDATION

FIG - FRAMEWORK INTEROPERABILITY GROUP

FIG formerly known as PHP standards group advocates a set of standards that have goal to unite frameworks such as Symfony, Lithium, CakePHP and others.

SF2 CODING STANDARDS

PSR-0 - AUTOLOADER STANDARD

  • __autoload()
  • spl_autoload()
  • spl_autoload_register()

With autoloading standards code can be easily reused across packages. You can either use PSR-0 compliant autoloader or you can let composer handle it for you.

 

Implementation of autoloader: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md#example-implementation

SF2 CODING STANDARDS

PSR-1 - BASIC CODING STANDARD

  • Only use the <?php and <?= tags.
  • Only use UTF-8 without BOM for PHP code.
  • Separate side-effects (generate output, access a database etc.) and declarations.
  • Enforce PSR-0.
  • Class names must be defined in StudlyCaps.
  • Class constants must be defined in upper case with underscore separators.
  • Method names must be defined in camelCase.

SF2 CODING STANDARDS

PSR-1 - BASIC CODING STANDARD

SF2 CODING STANDARDS

PSR-1 - BASIC CODING STANDARD

SF2 CODING STANDARDS

PSR-2 - Coding Style Guide

  • Code MUST use 4 spaces for indenting, not tabs.
  • There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
  • Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility; static MUST be declared after the visibility.
  • ...

More at https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

SF2 CODING STANDARDS

SF2 - NAMING CONVENTIONS

  • Use camelCase, not underscores, for variable, function and method names, arguments;
  • Use underscores for option names and parameter names;
  • Prefix abstract classes with Abstract. Please note some early Symfony classes do not follow this convention and have not been renamed for backward compatibility reasons. However all new abstract classes must follow this naming convention;
  • Suffix interfaces with Interface;
  • Suffix traits with Trait;
  • Suffix exceptions with Exception;
  • For type-hinting in PHPDocs and casting, use bool (instead of boolean or Boolean), int (instead of integer), float (instead of double or real);

SF2 CODING STANDARDS

SF2 - SERVICE NAMING CONVENTIONS

  • A service name contains groups, separated by dots;
  • The DI alias of the bundle is the first group (e.g. fos_user);
  • Use lowercase letters for service and parameter names;
  • A group name uses the underscore notation;
  • Each service has a corresponding parameter containing the class name, following the SERVICE NAME.class convention

SF2 BUndle INTEGRATION

  • ADD COMPOSER DEPENDENCIES
  • ADD BUNDLE TO APPKERNEL
  • CONFIGURE THE BUNDLE

SF2 BUndle INTEGRATION

RESOURCES TO DISCOVER NEW BUNDLES

  • http://knpbundles.com/
  • http://packagist.com/
  • http://github.com/

COMPOSER PACKAGES HANDLING

  • composer install
  • composer update

COMPOSER PACKAGES HANDLING

  • composer install
  • composer update
  • composer.lock
  • composer.json

SF2 DEVELOPMENT BEST PRACTICES

  • http://symfony.com/doc/2.3/best_practices/index.html
  • Keep TWIGs in app/Resources
  • Keep number of bundles small unless you're building something reusable
  • Use annotations for Doctrine mappings
  • Use annotations for routes
  • Use ParamConverter
  • ...

SF2 DEVELOPMENT BEST PRACTICES

  • http://symfony.com/doc/2.3/best_practices/index.html

Practices described in the book are good for most projects but some projects definitely require different approach.

OVERLOAD THE FRAMEWORK

OVERRIDING ROUTING

  • first matched served
  • php app/console router:debug
  • php app/console router:match

OVERLOAD THE FRAMEWORK

OVERRIDING TEMPLATES

  • app/Resources/NameOfBundle/ ...
  • override the bundle first and then override the templates

OVERLOAD THE FRAMEWORK

OVERRIDING CONTROLLERS

  • Override the bundle then override the controllers
  • The controllers should extend their respective base classes

OVERLOAD THE FRAMEWORK

OVERRIDING SERVICES & CONFIGURATION

  • create service with same ID
  • override the class parameter if it's available
  • use compiler passes

OVERLOAD THE FRAMEWORK

OVERRIDING ENTITIES AND MAPPING

  • Only possible if bundle provides mapped super-classes

OVERLOAD THE FRAMEWORK

OVERRIDING FORMS

  • form has to be defined as a service
  • then you override it as you would a typical service

OVERLOAD THE FRAMEWORK

OVERRIDING VALIDATION

  • you're not able to override validations but you can add new ones
  • it's possible only if 3rd party bundle has validation groups

OVERLOAD THE FRAMEWORK

OVERRIDING TRANSLATION

  • latest translation file wins
  • use translation domains

Standardisation

By Kruno Knego

Standardisation

Symfony2 standardisation. In-house education at Locastic.

  • 841
Loading comments...

More from Kruno Knego