DOCSEARCHbyAlgolia
Submit Docs

Symfony 6.4 Course

website·Indexed 30 days ago

https://ld-web.github.io/hb-sf-r6-course

A comprehensive guide and course for Symfony 6.4 LTS, covering core concepts including controllers, Twig templating, dependency injection, Doctrine ORM relations, and service configuration. The documentation includes practical tutorials on creating CRUD applications, implementing JWT authentication with LexikJWT, managing assets, and working with event listeners and subscribers.

Tokens
27.1K
Snippets
169
Records
213
Agent score
74%

What's inside Symfony

  1. Overview of API Platform features

    API Platform is a framework used to create and expose APIs from an existing application. It provides several native features:

    • RESTful API: Automatically generates a full CRUD based on Doctrine entities using standard HTTP verbs.
    • Swagger/OpenAPI: Auto-generates interactive API documentation accessible via the browser.
    • GraphQL: Supports exposing the API as a GraphQL service in addition to REST.
    • CORS & Authentication: Native support for CORS via nelmio/cors-bundle and JWT authentication via lexik/jwt-authentication-bundle.
    • JSON-LD & Hydra: Automatically includes machine-readable metadata. JSON-LD adds attributes like @id and @type. Hydra implements HATEOAS principles, providing hypermedia controls such as pagination (hydra:totalItems, hydra:view, hydra:next, etc.) in collection responses.

  2. Understand Symfony Autowiring for service injection

    Autowiring allows Symfony to automatically inject services into controller methods or class constructors based on type-hints. When a type-hint is encountered, Symfony searches the service container for a matching service. By default, all classes created in the src/ directory are registered as services and autowired using their Fully Qualified Class Name (FQCN) as the service ID, allowing repositories and other custom services to be injected without manual configuration.

  3. Understand Owning and Inverse sides in Doctrine relations

    In Doctrine, every relationship has an owning side and an inverse side. Doctrine only checks the owning side for changes to persist updates to the database. To ensure data is saved, you must modify the owning side of the relationship (e.g., using the setter on the owning entity).

    For OneToMany relations, the 'Many' side is always the owning side because it holds the foreign key in the database. For ManyToMany relations, the developer must manually decide which entity will be the owning side based on the desired application logic (e.g., which entity's form will be used to manage the association).

  4. Manage assets with Symfony AssetMapper

    Since Symfony 6.4, the AssetMapper component is used to manage CSS, Images, and JS. All assets are located in the assets directory at the project root. The main entry point is assets/app.js, where styles and other assets are imported using the import keyword. By default, assets/styles/app.css is imported in the entry point.
    // assets/app.js
import "./styles/app.css";

  5. Implement extensibility using the Symfony Event System

    The Symfony event system allows developers to add specific behaviors to an application without relying on class inheritance. It follows the Observer design pattern, enabling the definition of specific points in the application where external code can be executed. This is achieved by 'dispatching' an event at a specific moment, which is then 'listened to' by other parts of the code that execute their logic in response.

  6. Understand Doctrine ORM concepts in Symfony

    Doctrine is an Object-Relational Mapper (ORM) that allows developers to define the database model using PHP classes.

    • Entities: PHP classes that represent database tables. Properties within these classes are translated into table columns. Associations between entities are automatically translated into database relations.
    • Repositories: Classes generated for each entity used to perform database queries (e.g., finding a specific record or retrieving a list of elements).

  7. Understand the Symfony HttpKernel event system

    The symfony/http-kernel component is responsible for transforming a Request into a Response. It is event-driven, meaning it triggers specific events throughout its execution cycle. Developers can create 'event listeners'—classes containing code that executes when a specific kernel event is dispatched—allowing for the injection of custom logic without modifying every controller.

  8. Use Repositories as a service layer for database access

    In Symfony, repositories act as an application service layer used to interact with the database for specific entities. Repositories typically extend ServiceEntityRepository (which inherits from Doctrine's EntityRepository), providing built-in methods like find(), findAll(), and findBy() to retrieve data without writing manual SQL.
    // src/Repository/ArticleRepository.php
//... 
public function __construct(ManagerRegistry $registry)
{
    parent::__construct($registry, Article::class); // Reference to the Article entity
}

  9. Understand the Symfony application directory structure

    The Symfony project structure is organized into specific directories to separate concerns between the frontend, backend logic, configuration, and system files:

    • /assets: Frontend assets. Contains the main JS entry point (assets/app.js) and CSS files (e.g., assets/styles/app.css).
    • /bin: Contains executable binaries, most notably the console file used to run Symfony CLI commands for code generation and utility tasks.
    • /config: YAML configuration files for application packages. Includes bundles.php (to activate components per environment) and preload.php (for PHP 7.4+ script preloading).
    • /migrations: PHP classes describing database schema changes.
    • /public: The web root. Contains index.php, the single entry point for all application requests.
    • /src: The root directory for application PHP classes, mapped to the App\ namespace via PSR-4 autoloading. Key subdirectories include:
      • Controllers/: Logic for application pages.
      • Entity/: Database structure representations.
      • Repository/: Service layer for database queries.
    • /templates: Twig HTML templates.
    • /tests: Unit and functional tests.
    • /translations: Localization and multi-language label files.
    • /var: Cache and log data (typically excluded from version control). The cache folder contains compiled application container files.
    • /vendor: Third-party dependencies managed by Composer. This directory is not versioned and is generated via composer install.

  10. Understand the Symfony Serialization process

    Serialization is the process of transforming a PHP object into another format (such as JSON, XML, YAML, or CSV) so it can be stored in a database or read by other systems. In Symfony, the symfony/serializer component handles this via a two-step process:

    1. Normalization: Transforming the object or element into an array.
    2. Encoding: Transforming that array into the final target format (e.g., JSON).

    This process is essential when building APIs where the Symfony backend provides raw data to a JavaScript frontend.

  11. Use Symfony Mailer for sending emails

    To implement email functionality (such as newsletter registration confirmations) in a Symfony application, use the symfony/mailer component. If the application was installed using the webapp pack rather than as a simple API, this component is included by default in the project dependencies.
    {
  "require": {
    "symfony/mailer": "6.4.*"
  }
}

  12. Manage application security with the Symfony Security Bundle

    Security in a Symfony application is managed by the Security Bundle. This bundle integrates three core packages to provide authentication, authorization, and access control functionality:

    • symfony/security-core: Core security logic.
    • symfony/security-csrf: Cross-Site Request Forgery (CSRF) protection.
    • symfony/security-http: HTTP-specific security integration.