mirror of
https://github.com/symfony/symfony-docs.git
synced 2026-03-24 00:32:14 +01:00
Merge branch '7.2' into 7.3
* 7.2: Fix a minor RST syntax issue Improve grammar and expressions for American English
This commit is contained in:
@@ -10,7 +10,7 @@ You can even ignore them completely and continue using your own best practices
|
||||
and methodologies. Symfony is flexible enough to adapt to your needs.
|
||||
|
||||
This article assumes that you already have experience developing Symfony
|
||||
applications. If you don't, read first the :doc:`Getting Started </setup>`
|
||||
applications. If you don't, first read the :doc:`Getting Started </setup>`
|
||||
section of the documentation.
|
||||
|
||||
.. tip::
|
||||
@@ -118,7 +118,7 @@ Use Short and Prefixed Parameter Names
|
||||
|
||||
Consider using ``app.`` as the prefix of your :ref:`parameters <configuration-parameters>`
|
||||
to avoid collisions with Symfony and third-party bundles/libraries parameters.
|
||||
Then, use just one or two words to describe the purpose of the parameter:
|
||||
Then, use only one or two words to describe the purpose of the parameter:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ The Bundle System
|
||||
|
||||
A bundle is similar to a plugin in other software, but even better. The core
|
||||
features of Symfony framework are implemented with bundles (FrameworkBundle,
|
||||
SecurityBundle, DebugBundle, etc.) They are also used to add new features in
|
||||
SecurityBundle, DebugBundle, etc.) Bundles are also used to add new features in
|
||||
your application via `third-party bundles`_.
|
||||
|
||||
Bundles used in your applications must be enabled per
|
||||
@@ -42,7 +42,7 @@ file::
|
||||
Creating a Bundle
|
||||
-----------------
|
||||
|
||||
This section creates and enables a new bundle to show there are only a few steps required.
|
||||
This section creates and enables a new bundle to show that only a few steps are required.
|
||||
The new bundle is called AcmeBlogBundle, where the ``Acme`` portion is an example
|
||||
name that should be replaced by some "vendor" name that represents you or your
|
||||
organization (e.g. AbcBlogBundle for some company named ``Abc``).
|
||||
|
||||
@@ -32,12 +32,11 @@ You can read more about these at the :doc:`component documentation </components/
|
||||
Configuring Cache with FrameworkBundle
|
||||
--------------------------------------
|
||||
|
||||
When configuring the cache component there are a few concepts you should know
|
||||
of:
|
||||
When configuring the cache component there are a few concepts you should know:
|
||||
|
||||
**Pool**
|
||||
This is a service that you will interact with. Each pool will always have
|
||||
its own namespace and cache items. There is never a conflict between pools.
|
||||
its own namespace and cache items. There are never conflicts between pools.
|
||||
**Adapter**
|
||||
An adapter is a *template* that you use to create pools.
|
||||
**Provider**
|
||||
|
||||
@@ -37,7 +37,7 @@ example, this is the default file created by the "API Platform" bundle:
|
||||
mapping:
|
||||
paths: ['%kernel.project_dir%/src/Entity']
|
||||
|
||||
Splitting the configuration into lots of small files might appear intimidating for some
|
||||
Splitting the configuration into lots of small files might seem intimidating to some
|
||||
Symfony newcomers. However, you'll get used to them quickly and you rarely need
|
||||
to change these files after package installation.
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ class::
|
||||
The controller is the ``number()`` method, which lives inside the
|
||||
controller class ``LuckyController``.
|
||||
|
||||
This controller is pretty straightforward:
|
||||
This controller is quite simple:
|
||||
|
||||
* *line 2*: Symfony takes advantage of PHP's namespace functionality to
|
||||
namespace the entire controller class.
|
||||
|
||||
@@ -5,7 +5,7 @@ How to Deploy a Symfony Application
|
||||
|
||||
Deploying a Symfony application can be a complex and varied task depending on
|
||||
the setup and the requirements of your application. This article is not a
|
||||
step-by-step guide, but is a general list of the most common requirements and
|
||||
step-by-step guide, but rather a general list of the most common requirements and
|
||||
ideas for deployment.
|
||||
|
||||
.. _symfony2-deployment-basics:
|
||||
|
||||
@@ -509,7 +509,7 @@ A ``kernel.controller`` (aka ``KernelEvents::CONTROLLER``) listener gets notifie
|
||||
on *every* request, right before the controller is executed. So, first, you need
|
||||
some way to identify if the controller that matches the request needs token validation.
|
||||
|
||||
A clean and easy way is to create an empty interface and make the controllers
|
||||
A clean and simple way is to create an empty interface and make the controllers
|
||||
implement it::
|
||||
|
||||
namespace App\Controller;
|
||||
|
||||
@@ -19,7 +19,7 @@ The Symfony cache system is different because it relies on the simplicity
|
||||
and power of the HTTP cache as defined in `RFC 7234 - Caching`_. Instead of
|
||||
reinventing a caching methodology, Symfony embraces the standard that defines
|
||||
basic communication on the Web. Once you understand the fundamental HTTP
|
||||
validation and expiration caching models, you'll be ready to master the Symfony
|
||||
validation and expiration caching models, you'll be ready to understand the Symfony
|
||||
cache system.
|
||||
|
||||
Since caching with HTTP isn't unique to Symfony, many articles already exist
|
||||
|
||||
2
lock.rst
2
lock.rst
@@ -1,7 +1,7 @@
|
||||
Dealing with Concurrency with Locks
|
||||
===================================
|
||||
|
||||
When a program runs concurrently, some part of code which modify shared
|
||||
When a program runs concurrently, some parts of code that modify shared
|
||||
resources should not be accessed by multiple processes at the same time.
|
||||
Symfony's :doc:`Lock component </components/lock>` provides a locking mechanism to ensure
|
||||
that only one process is running the critical section of code at any point of
|
||||
|
||||
@@ -157,7 +157,7 @@ You'll now have a new line in your ``.env`` file that you can uncomment:
|
||||
|
||||
The ``MAILER_DSN`` isn't a *real* address: it's a convenient format that
|
||||
offloads most of the configuration work to mailer. The ``sendgrid`` scheme
|
||||
activates the SendGrid provider that you just installed, which knows all about
|
||||
activates the SendGrid provider that you installed, which knows all about
|
||||
how to deliver messages via SendGrid. The *only* part you need to change is the
|
||||
``KEY`` placeholder.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ notifying the user when :doc:`an asynchronous job </messenger>` has been
|
||||
completed or creating chat applications are among the typical use cases
|
||||
requiring "push" capabilities.
|
||||
|
||||
Symfony provides a straightforward component, built on top of
|
||||
Symfony provides a simple component, built on top of
|
||||
`the Mercure protocol`_, specifically designed for this class of use cases.
|
||||
|
||||
Mercure is an open protocol designed from the ground up to publish updates from
|
||||
|
||||
@@ -3,7 +3,7 @@ Messenger: Sync & Queued Message Handling
|
||||
|
||||
Messenger provides a message bus with the ability to send messages and then
|
||||
handle them immediately in your application or send them through transports
|
||||
(e.g. queues) to be handled later. To learn more deeply about it, read the
|
||||
(e.g. queues) to be handled later. To learn more about it, read the
|
||||
:doc:`Messenger component docs </components/messenger>`.
|
||||
|
||||
Installation
|
||||
|
||||
@@ -273,10 +273,10 @@ when needed.
|
||||
What's Next?
|
||||
------------
|
||||
|
||||
Congrats! You're already starting to master Symfony and learn a whole new
|
||||
Congrats! You're already starting to learn Symfony and discover a whole new
|
||||
way of building beautiful, functional, fast and maintainable applications.
|
||||
|
||||
OK, time to finish mastering the fundamentals by reading these articles:
|
||||
OK, time to finish learning the fundamentals by reading these articles:
|
||||
|
||||
* :doc:`/routing`
|
||||
* :doc:`/controller`
|
||||
|
||||
@@ -23,7 +23,7 @@ because it's convenient to put the route and controller in the same place.
|
||||
Creating Routes as Attributes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
PHP attributes allow to define routes next to the code of the
|
||||
PHP attributes allow you to define routes next to the code of the
|
||||
:doc:`controllers </controller>` associated to those routes.
|
||||
|
||||
You need to add a bit of configuration to your project before using them. If your
|
||||
|
||||
@@ -43,7 +43,7 @@ creates a ``security.yaml`` configuration file for you:
|
||||
# https://symfony.com/doc/current/security/impersonating_user.html
|
||||
# switch_user: true
|
||||
|
||||
# Easy way to control access for large sections of your site
|
||||
# An easy way to control access for large sections of your site
|
||||
# Note: Only the *first* access control that matches will be used
|
||||
access_control:
|
||||
# - { path: ^/admin, roles: ROLE_ADMIN }
|
||||
|
||||
@@ -10,7 +10,7 @@ to a PHP object that is consumed by your application. Then, when generating
|
||||
the response, you can use the serializer to transform the PHP objects back
|
||||
to a JSON response.
|
||||
|
||||
It can also be used to for instance load CSV configuration data as PHP
|
||||
It can also be used to, for instance, load CSV configuration data as PHP
|
||||
objects, or even to transform between formats (e.g. YAML to XML).
|
||||
|
||||
.. _activating_the_serializer:
|
||||
|
||||
@@ -16,7 +16,7 @@ Types of Tests
|
||||
There are many types of automated tests and precise definitions often
|
||||
differ from project to project. In Symfony, the following definitions are
|
||||
used. If you have learned something different, that is not necessarily
|
||||
wrong, just different from what the Symfony documentation is using.
|
||||
wrong, merely different from what the Symfony documentation is using.
|
||||
|
||||
`Unit Tests`_
|
||||
These tests ensure that *individual* units of source code (e.g. a single
|
||||
@@ -402,11 +402,11 @@ test finishes to undo all changes. Read more in the documentation of the
|
||||
|
||||
.. _doctrine-fixtures:
|
||||
|
||||
Load Dummy Data Fixtures
|
||||
........................
|
||||
Load Test Data Fixtures
|
||||
.......................
|
||||
|
||||
Instead of using the real data from the production database, it's common to
|
||||
use fake or dummy data in the test database. This is usually called
|
||||
use fake or test data in the test database. This is usually called
|
||||
*"fixtures data"* and Doctrine provides a library to create and load them.
|
||||
Install it with:
|
||||
|
||||
|
||||
@@ -733,7 +733,7 @@ You'll now have a new line in your ``.env`` file that you can uncomment:
|
||||
|
||||
The ``LOCO_DSN`` isn't a *real* address: it's a convenient format that offloads
|
||||
most of the configuration work to Symfony. The ``loco`` scheme activates the
|
||||
Loco provider that you just installed, which knows all about how to push and
|
||||
Loco provider that you installed, which knows all about how to push and
|
||||
pull translations via Loco. The *only* part you need to change is the
|
||||
``API_KEY`` placeholder.
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
Workflow
|
||||
========
|
||||
|
||||
Using the Workflow component inside a Symfony application requires knowing first
|
||||
Using the Workflow component inside a Symfony application requires first knowing
|
||||
some basic theory and concepts about workflows and state machines.
|
||||
:doc:`Read this article </workflow/workflow-and-state-machine>` for a quick overview.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user