-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reviewed the Bundles cookbook articles #5095
Merged
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
8254761
Reviewed the Bundles cookbook articles
javiereguiluz 3dd40b2
Fixed an internal link reference
javiereguiluz c0637b6
Implemented the changes suggested by reviewers
javiereguiluz 8861215
Replace phpDocumentor by the standard PHPDoc
javiereguiluz 8008ac6
Implemented the suggestions made by Christian and Wouter
javiereguiluz File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,7 +4,7 @@ | |
Best Practices for Reusable Bundles | ||
=================================== | ||
|
||
There are 2 types of bundles: | ||
There are two types of bundles: | ||
|
||
* Application-specific bundles: only used to build your application; | ||
* Reusable bundles: meant to be shared across many projects. | ||
|
@@ -13,12 +13,8 @@ This article is all about how to structure your **reusable bundles** so that | |
they're easy to configure and extend. Many of these recommendations do not | ||
apply to application bundles because you'll want to keep those as simple | ||
as possible. For application bundles, just follow the practices shown throughout | ||
the book and cookbook. | ||
|
||
.. seealso:: | ||
|
||
The best practices for application-specific bundles are discussed in | ||
:doc:`/best_practices/introduction`. | ||
the :doc:`book </book/index>`, the :doc:`cookbook </cookbook/index>` and the | ||
:doc:`best practices </best_practices/index>` book. | ||
|
||
.. index:: | ||
pair: Bundle; Naming conventions | ||
|
@@ -38,7 +34,7 @@ bundle class name must follow these simple rules: | |
|
||
* Use only alphanumeric characters and underscores; | ||
* Use a CamelCased name; | ||
* Use a descriptive and short name (no more than 2 words); | ||
* Use a descriptive and short name (no more than two words); | ||
* Prefix the name with the concatenation of the vendor (and optionally the | ||
category namespaces); | ||
* Suffix the name with ``Bundle``. | ||
|
@@ -112,7 +108,7 @@ The following files are mandatory: | |
structure to work. | ||
|
||
The depth of sub-directories should be kept to the minimal for most used | ||
classes and files (2 levels at a maximum). More levels can be defined for | ||
classes and files (two levels at a maximum). More levels can be defined for | ||
non-strategic, less-used files. | ||
|
||
The bundle directory is read-only. If you need to write temporary files, store | ||
|
@@ -158,7 +154,7 @@ instance, a ``HelloController`` controller is stored in | |
``Bundle/HelloBundle/Controller/HelloController.php`` and the fully qualified | ||
class name is ``Bundle\HelloBundle\Controller\HelloController``. | ||
|
||
All classes and files must follow the Symfony coding :doc:`standards </contributing/code/standards>`. | ||
All classes and files must follow the :doc:`Symfony coding standards </contributing/code/standards>`. | ||
|
||
Some classes should be seen as facades and should be as short as possible, like | ||
Commands, Helpers, Listeners, and Controllers. | ||
|
@@ -181,7 +177,7 @@ Tests | |
----- | ||
|
||
A bundle should come with a test suite written with PHPUnit and stored under | ||
the ``Tests/`` directory. Tests should follow the following principles: | ||
the ``Tests/`` directory. Tests should follow these principles: | ||
|
||
* The test suite must be executable with a simple ``phpunit`` command run from | ||
a sample application; | ||
|
@@ -190,13 +186,14 @@ the ``Tests/`` directory. Tests should follow the following principles: | |
* The tests should cover at least 95% of the code base. | ||
|
||
.. note:: | ||
|
||
A test suite must not contain ``AllTests.php`` scripts, but must rely on the | ||
existence of a ``phpunit.xml.dist`` file. | ||
|
||
Documentation | ||
------------- | ||
|
||
All classes and functions must come with full PHPDoc. | ||
All classes and functions must be fully documented using `PHPDoc`_ tags. | ||
|
||
Extensive documentation should also be provided in the | ||
:doc:`reStructuredText </contributing/documentation/format>` format, under | ||
|
@@ -306,8 +303,11 @@ following standardized instructions in your ``README.md`` file. | |
|
||
.. _`installation chapter`: https://getcomposer.org/doc/00-intro.md | ||
|
||
This template assumes that your bundle is in its ``1.x`` version. If not, change | ||
the ``"~1"`` installation version accordingly (``"~2"``, ``"~3"``, etc.) | ||
The example above assumes that you are installing the latest stable version of | ||
the bundle, where you don't have to provide the package version number | ||
(e.g. ``composer require friendsofsymfony/user-bundle``). If the installation | ||
instructions refer to some past bundle version or to some inestable version, | ||
include the version constraint (e.g. ``composer require friendsofsymfony/user-bundle "~2.0@dev"``). | ||
|
||
Optionally, you can add more installation steps (*Step 3*, *Step 4*, etc.) to | ||
explain other required installation tasks, such as registering routes or | ||
|
@@ -330,7 +330,8 @@ Translation Files | |
----------------- | ||
|
||
If a bundle provides message translations, they must be defined in the XLIFF | ||
format; the domain should be named after the bundle name (``bundle.hello``). | ||
format; the :ref:`translation domain <using-message-domains>` should be named | ||
after the bundle name (``bundle.hello``). | ||
|
||
A bundle must not override existing messages from another bundle. | ||
|
||
|
@@ -369,27 +370,17 @@ The end user can provide values in any configuration file: | |
// app/config/config.php | ||
$container->setParameter('acme_hello.email.from', '[email protected]'); | ||
|
||
.. code-block:: ini | ||
|
||
; app/config/config.ini | ||
[parameters] | ||
acme_hello.email.from = [email protected] | ||
|
||
Retrieve the configuration parameters in your code from the container:: | ||
|
||
$container->getParameter('acme_hello.email.from'); | ||
|
||
Even if this mechanism is simple enough, you are highly encouraged to use the | ||
semantic configuration described in the cookbook. | ||
:doc:`semantic bundle configuration </cookbook/bundles/extension>` instead. | ||
|
||
.. note:: | ||
|
||
If you are defining services, they should also be prefixed with the bundle | ||
alias. | ||
|
||
Learn more from the Cookbook | ||
---------------------------- | ||
|
||
* :doc:`/cookbook/bundles/extension` | ||
|
||
.. _standards: http://www.php-fig.org/psr/psr-4/ | ||
.. _`standards`: http://www.php-fig.org/psr/psr-0/ | ||
.. _`PHPDoc`: https://en.wikipedia.org/wiki/PHPDoc |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really get why this change is usefull
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A good practice when using acronyms is to introduce them properly before the first time they are used. In this article, we talk about
Dependency Injection
and suddenly, the article talks aboutDI
. I know that Symfony developers are smart enough to infere thatDI
meansDependency Injection
, but the usual good practice is to show the full words + its acronym just before starting to use the acronym exclusively.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also just avoid using DI in the docs (which imho were a better practice). But as long as we use them it's imho indeed a good idea to introduce it properly.