Image for post: Zurb Foundation and HTML5 accessibility

Zurb Foundation and HTML5 accessibility

29 November 2016 Estimated reading time: 4 minutes HTML and CSS 

Ok this year Symfony3 will be launched but in the best practice book there are some good recommendations and warning for the next future. I'll try to summarize the most interesting concepts and warnings. There are a lot hints about what you can or must do and some warning about common mistakes and what you must not do.

Configurations

  • Define the infrastructure-related configuration options in the app/config/parameters.yml file
  • Define all your application's parameters in the app/config/parameters.yml.dist file
  • Define the application behavior related configuration options in the app/config/config.yml file
  • Use constants to define configuration options that rarely change. Example: the number of posts elements to display in a page can be defined in the Post Entity repository as a constant rather than in the config.yml file.
  • Don't define a semantic dependency injection configuration for your bundles. See the article: "How to Load Service Configuration inside a Bundle"
  • See the article: "How to Set external Parameters in the Service Container".

Organizing the business logic

  • Don't put classes outside of bundle\s if not necessary
  • Use the YAML format to define your own services
  • You can  create data fixtures for the entity to test it
  • The Symfony source code follows the PSR-1 and PSR-2 coding standards. Read the page about Symfony coding standard.

Controllers

  •  Symfony follows the philosophy of "thin controllers and fat models". Controllers should hold just the thin layer of glue-code needed to coordinate the different parts of the application
  • Use the ParamConverter trick to automatically query for Doctrine entities when it's simple and convenient
  • You can use the EventDispatcher component to How to Setup before and after Filters

Templates

  • Store all your application's templates in app/Resources/views/ directory
  • Don't use the @Template() annotation to configure the template used by the controller
  • Define your Twig extensions in the AppBundle/Twig/ directory and configure them using the app/config/ services.yml file

Forms

  • Define your forms as PHP classes
  • You can also register your form type as a service. But this is not recommended unless you plan to reuse the new form type in many places or embed it in other forms directly or via the collection type
  • Add buttons in the templates, not in the form classes or the controllers
  • Rendering forms: How to Customize Form Rendering. With Symfony 2.6 you can use a bootstrap3 tempalte to render some forms or all of them.
  • Handling form submits: use both conditions if ($form->isSubmitted() && $form->isValid()) {}.

Security and Authentication

  • Unless you have two legitimately different authentication systems and users (e.g. form login for the main site and a token system for your API only), we recommend having only one firewall entry with the anonymous key enabled
  • Use the bcrypt encoder for encoding your users' passwords.

Authorization (i.e. Denying Access)

Symfony gives you several ways to enforce authorization, including the access_control configuration in security.yml, the @Security annotation and using isGranted on the security.authorization_checker service directly.

  • For protecting broad URL patterns, use access_control;
  • Whenever possible, use the @Security annotation;
  • Check security directly on the security.authorization_checker service whenever you have a more complex situation.

Centralize your authorization logic:

  • For fine-grained restrictions, define a custom security voter
  • For restricting access to any object by any user via an admin interface, use the Symfony ACL

Take a look at the @Security annotation and the possibility to use expressions and the new Voter class available from Symfony 2.6. The FOSUserBundle is developed by the Symfony community. You may need the Remember me feature, the possibility to impersonate users. If your company uses a user login method not supported by Symfony, you can develop your own user provider and your own authentication provider.

Internationalization

  • Put tranlation files all in app\Resources\translations
  • Use xliff files for tranlations: (Note: I prefer using yml files. They are more short and readable. I don't know why they recommend to use this format, maybe because it's a standard for translation files)

Web assets

  • Store your assets in the web/ directory
  • Use Assetic to compile, combine and minimize web assets, unless you're comfortable with frontend tools like GruntJS

Tests

  • Define a functional test that at least checks if your application pages are successfully loading.
  • Hardcode the URLs used in the functional tests instead of using the URL generator.
  • If your frontend contains more Javascript you can use Mink or consider some Javascript testing tools like Qunit, Protractor, Karma, Jasmine and many more even if they are different between them.
  • Consider using Faker and Alice libraries to generate real-looking data for your test fixtures

Conclusion

These are only informations about following best practices. If you need some detailed documentation you can read the Symfony book or the Cookbook downloading them from the Symfony website.

Tags

Framework