Symfony

Components

HttpFoundation Component: The HttpFoundation component defines an object-oriented layer for the HTTP specification.
HttpKernel Component: The HttpKernel component provides a structured process for converting a Request into a Response by making use of the EventDispatcher component
EventDispatcher Component: Provides tools that allow your application components to communicate with each other by dispatching events and listening to them
Routing Component: Maps an HTTP request to a set of configuration variables.
DependencyInjection Component: The DependencyInjection component implements a PSR-11 compatible service container that allows you to standardize and centralize the way objects are constructed in your application.
Security Component: Authentication and authorization
Validator Component: Provides tools to ensure that the data of any complex data structure are valid.
Serializer Component: Turns objects into a specific format (like JSON, XML) and the other way around.
Templating Component: Provides all the tools needed to build any kind of template system.
Translation Component: Provides tools for internationalization and localization of your application's messages.
Form Component: Allows you to easily create, process, and reuse HTML forms.
Console Component: Eases the creation of beautiful and testable command-line interfaces.
Asset Component: Manages URL generation and versioning of web assets such as CSS stylesheets, JavaScript files, and image files.
Workflow Component: Provides tools for managing a workflow or finite state machine.
Messenger Component: Helps applications send and receive messages to/from other applications or via message queues.
HttpClient Component: Provides powerful methods to fetch HTTP resources synchronously or asynchronously.

Symfony Flex

Symfony Flex is a composer plugin that is installed by default when creating a new Symfony application. It seamlessly integrates with Composer's workflow and enhances it with additional features.

Recipe Concept: Flex introduces the concept of a "recipe," which is a set of automated instructions that tell Flex how to install and configure Symfony bundles or any other type of package (like setting up a file structure, enabling new configuration settings, creating environment variables, etc.). Official recipes are stored in a public GitHub repository called "recipes-contrib."

https://github.com/symfony/recipes/blob/flex/main/RECIPES.md

composer require twig

First, twig is not the name of a Composer package: it's a Flex alias that points to symfony/twig-bundle. Flex resolves that alias for Composer.

And second, Flex installs a recipe for symfony/twig-bundle. It creates configuration yml files and added a folder.

What's a recipe? It's a way for a library to automatically configure itself by adding and modifying files. Thanks to recipes, adding features is seamless and automated: install a package and you're done!

Bundle, vendor, bridge

Bundle

A Symfony bundle is a collection of files and folders organized in a specific structure. The bundles are modeled in such a way that it can be reused in multiple applications.

A part of your application which owns a logic (controllers, views, models).

Bundles can also wrap a library. For example, the BazingaGeocoderBundle wraps the Geocoder library. It provides Symfony2 oriented features to ease the use of a library in a Symfony2 project. Also, it can be a glue between components.

In Symfony versions prior to 4.0, it was recommended to organize your own application code using bundles. This is no longer recommended and bundles should only be used to share code and features between multiple applications.

Vendor

In general, vendor are the dependencies of your project (aka third party libraries). It's the same meaning in Symfony2.

Bridge

They serve as a connection or "bridge" between Symfony and other libraries or platforms, ensuring they work seamlessly together.

In some cases, a library might have both a bridge and a bundle. The bridge would provide the essential compatibility layer, while the bundle would provide the higher-level features, configuration, and integration into the Symfony application.

Business Logic

Don't Create any Bundle to Organize your Application Logic

When Symfony 2.0 was released, applications used bundles to divide their code into logical features: UserBundle, ProductBundle, InvoiceBundle, etc. However, a bundle is meant to be something that can be reused as a stand-alone piece of software.

If you need to reuse some feature in your projects, create a bundle for it (in a private repository, do not make it publicly available). For the rest of your application code, use PHP namespaces to organize code instead of bundles.

Use Autowiring to Automate the Configuration of Application Services

Service autowiring is a feature that reads the type-hints on your constructor (or other methods) and automatically passes the correct services to each method, making it unnecessary to configure services explicitly and simplifying the application maintenance.

Use it in combination with service autoconfiguration to also add service tags to the services needing them, such as Twig extensions, event subscribers, etc.

Services Should be Private Whenever Possible

Make services private to prevent you from accessing those services via $container->get(). Instead, you will need to use proper dependency injection.

Use the YAML Format to Configure your own Services

If you use the default services.yaml configuration, most services will be configured automatically. However, in some edge cases you'll need to configure services (or parts of them) manually.

YAML is the format recommended configuring services because it's friendly to newcomers and concise, but Symfony also supports XML and PHP configuration.

Use Attributes to Define the Doctrine Entity Mapping

Doctrine entities are plain PHP objects that you store in some "database". Doctrine only knows about your entities through the mapping metadata configured for your model classes.

Doctrine supports several metadata formats, but it's recommended to use PHP attributes because they are by far the most convenient and agile way of setting up and looking for mapping information.

If your PHP version doesn't support attributes yet, use annotations, which is similar but requires installing some extra dependencies in your project.

Property accessor

// ARRAY
$person = ['first_name' => 'Wouter' ];

var_dump($propertyAccessor->getValue($person, '[first_name]')); // 'Wouter'
var_dump($propertyAccessor->getValue($person, '[age]')); // null
// You can avoid the exception by adding the nullsafe operator
$value = $propertyAccessor->getValue($person, '[age?]');

// OBJECT
$person = new Person();
$person->firstName = 'Wouter';
var_dump($propertyAccessor->getValue($person, 'firstName')); // 'Wouter'

unified api, safe access

// Before Property Access
if ($data && isset($data['user']) && isset($data['user']['name'])) {
    $name = $data['user']['name'];
} else {
    $name = 'Unknown';
}

$name = $propertyAccessor->getValue($data, '[user][name]', 'Unknown');

// Before Property Access
if ($order && $order->getCustomer() && $order->getCustomer()->getAddresses() && count($order->getCustomer()->getAddresses()) > 0) {
    $firstAddress = $order->getCustomer()->getAddresses()[0];
} else {
    $firstAddress = null;
}
// after
$firstAddress = $propertyAccessor->getValue($order, 'customer.addresses[0]');

// Before Property Access
if ($data && isset($data['user']) && isset($data['user']['name'])) {
    $name = $data['user']['name'];
} else {
    $name = 'Unknown';
}
//After
$name = $propertyAccessor->getValue($data, '[user][name]', 'Unknown');

Param converter

Automatically done from symfony 6.2

#[Route('/blog/{slug}', name: 'blog_show')]
    public function show(BlogPost $post): Response
    {
        // $post is the object whose slug matches the routing parameter

        // ...
    }

Options resolver

The OptionsResolver component is an improved replacement for the array_replace PHP function. It allows you to create an options system with required options, defaults, validation (type, value), normalization and more.

public function __construct(array $options = [])
    {
        $this->options = array_replace([
            'host'     => 'smtp.example.org',
            'username' => 'user',
            'password' => 'pa$$word',
            'port'     => 25,
        ], $options);
    }

public function __construct(array $options = [])
    {
        $resolver = new OptionsResolver();
				$resolver->setRequired('host');
				$resolver->setAllowedTypes('host', 'string');

        $resolver->setDefaults([
            'host'     => 'smtp.example.org',
            'username' => 'user',
            'password' => 'pa$$word',
            'port'     => 25,
        ]);

        $this->options = $resolver->resolve($options);
    }

Built-in events

kernel.request: Triggered on every request and allows you to modify the request or return a response.
kernel.controller: Fired before the controller is called. This allows you to change the controller that should be executed.
kernel.controller_arguments: Triggered after the controller has been resolved and right before calling it. This allows you to modify the arguments passed to the controller.
kernel.view: Allows transforming the controller result into a Response. It's called when the controller returns a value that is not a Response object.
kernel.response: Called after the controller returns a response. This allows you to modify or replace the response object.
kernel.terminate: Triggered after the response has been sent, allowing for "post-response" processing.
kernel.exception: Fired when an exception is thrown. It allows you to create a response for the exception or modify the thrown exception.

PreviousPHP Questions NextService container

Last updated 15 days ago