minor #4865 Removed literals for bundle names (WouterJ)

This PR was merged into the 2.3 branch.

Discussion
----------

Removed literals for bundle names

*Note: Most of it was automated and I didn't review it closely yet (since I didn't know the general opinion on this topic), so there can be some faulty changes.*

I always like to use as less literals as possible, as I think it makes sentences harder to understand. That's why I strongly believe that literals should exclusively be used for code. As a bundle name is not code, I propose to remove all literals around bundle names.

| Q   | A
| --- | ---
| Doc fix? | yes
| New docs? | nope
| Applies to | all
| Fixed tickets | -

Commits
-------

f361c87 Removed literals for bundle names

Author: weaverryan

best_practices/business-logic.rst

@@ -10,7 +10,7 @@ your app that's not specific to the framework (e.g. routing and controllers).
 Domain classes, Doctrine entities and regular PHP classes that are used as
 services are good examples of business logic.
 
-For most projects, you should store everything inside the ``AppBundle``.
+For most projects, you should store everything inside the AppBundle.
 Inside here, you can create whatever directories you want to organize things:
 
 .. code-block:: text
@@ -45,7 +45,7 @@ and put things there:
 
 .. tip::
 
-    The recommended approach of using the ``AppBundle`` directory is for
+    The recommended approach of using the ``AppBundle/`` directory is for
     simplicity. If you're advanced enough to know what needs to live in
     a bundle and what can live outside of one, then feel free to do that.
 
@@ -166,8 +166,8 @@ library or strategy you want for this.
 
 In practice, many Symfony applications rely on the independent
 `Doctrine project`_ to define their model using entities and repositories.
-Just like with business logic, we recommend storing Doctrine entities in
-the ``AppBundle``
+Just like with business logic, we recommend storing Doctrine entities in the
+AppBundle.
 
 The three entities defined by our sample blog application are a good example:
 

best_practices/controllers.rst

@@ -13,8 +13,8 @@ into a service.
 
 .. best-practice::
 
-    Make your controller extend the ``FrameworkBundle`` base Controller and
-    use annotations to configure routing, caching and security whenever possible.
+    Make your controller extend the FrameworkBundle base controller and use
+    annotations to configure routing, caching and security whenever possible.
 
 Coupling the controllers to the underlying framework allows you to leverage
 all of its features and increases your productivity.

best_practices/creating-the-project.rst

@@ -109,26 +109,26 @@ Application Bundles
 
 When Symfony 2.0 was released, most developers naturally adopted the symfony
 1.x way of dividing applications into logical modules. That's why many Symfony
-apps use bundles to divide their code into logical features: ``UserBundle``,
-``ProductBundle``, ``InvoiceBundle``, etc.
+apps use bundles to divide their code into logical features: UserBundle,
+ProductBundle, InvoiceBundle, etc.
 
 But a bundle is *meant* to be something that can be reused as a stand-alone
-piece of software. If ``UserBundle`` cannot be used *"as is"* in other Symfony
-apps, then it shouldn't be its own bundle. Moreover ``InvoiceBundle`` depends
-on ``ProductBundle``, then there's no advantage to having two separate bundles.
+piece of software. If UserBundle cannot be used *"as is"* in other Symfony
+apps, then it shouldn't be its own bundle. Moreover InvoiceBundle depends on
+ProductBundle, then there's no advantage to having two separate bundles.
 
 .. best-practice::
 
-    Create only one bundle called ``AppBundle`` for your application logic
+    Create only one bundle called AppBundle for your application logic
 
-Implementing a single ``AppBundle`` bundle in your projects will make your code
+Implementing a single AppBundle bundle in your projects will make your code
 more concise and easier to understand. Starting in Symfony 2.6, the official
-Symfony documentation uses the ``AppBundle`` name.
+Symfony documentation uses the AppBundle name.
 
 .. note::
 
-    There is no need to prefix the ``AppBundle`` with your own vendor (e.g.
-    ``AcmeAppBundle``), because this application bundle is never going to be
+    There is no need to prefix the AppBundle with your own vendor (e.g.
+    AcmeAppBundle), because this application bundle is never going to be
     shared.
 
 All in all, this is the typical directory structure of a Symfony application
@@ -152,7 +152,7 @@ that follows these best practices:
 
 .. tip::
 
-    If your Symfony installation doesn't come with a pre-generated ``AppBundle``,
+    If your Symfony installation doesn't come with a pre-generated AppBundle,
     you can generate it by hand executing this command:
 
     .. code-block:: bash

book/controller.rst

@@ -228,9 +228,9 @@ Simple, right?
 Route Parameters as Controller Arguments
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You already know that the route points to the ``HelloController::indexAction()`` method
-that lives inside ``AppBundle``. What's more interesting is the argument
-that is passed to that method::
+You already know that the route points to the
+``HelloController::indexAction()`` method that lives inside AppBundle. What's
+more interesting is the argument that is passed to that method::
 
     // src/AppBundle/Controller/HelloController.php
     // ...
@@ -768,8 +768,8 @@ object that's returned from *that* controller::
 Notice that the ``forward()`` method uses a special string representation
 of the controller (see :ref:`controller-string-syntax`). In this case, the
 target controller function will be ``SomethingController::fancyAction()``
-inside the ``AppBundle``. The array passed to the method becomes the arguments
-on the resulting controller. This same idea is used when embedding controllers
+inside the AppBundle. The array passed to the method becomes the arguments on
+the resulting controller. This same idea is used when embedding controllers
 into templates (see :ref:`templating-embedding-controller`). The target
 controller method would look something like this::
 

book/doctrine.rst

@@ -197,7 +197,7 @@ Creating an Entity Class
 Suppose you're building an application where products need to be displayed.
 Without even thinking about Doctrine or databases, you already know that
 you need a ``Product`` object to represent those products. Create this class
-inside the ``Entity`` directory of your ``AppBundle``::
+inside the ``Entity`` directory of your AppBundle::
 
     // src/AppBundle/Entity/Product.php
     namespace AppBundle\Entity;

book/page_creation.rst

@@ -101,12 +101,12 @@ to a specific feature, including PHP classes, configuration, and even stylesheet
 and JavaScript files (see :ref:`page-creation-bundles`).
 
 Depending on the way you installed Symfony, you may already have a bundle called
-``AcmeDemoBundle``. Browse the ``src/`` directory of your project and check
+AcmeDemoBundle. Browse the ``src/`` directory of your project and check
 if there is a ``DemoBundle/`` directory inside an ``Acme/`` directory. If those
 directories already exist, skip the rest of this section and go directly to
 create the route.
 
-To create a bundle called ``AcmeDemoBundle`` (a play bundle that you'll
+To create a bundle called AcmeDemoBundle (a play bundle that you'll
 build in this chapter), run the following command and follow the on-screen
 instructions (use all the default options):
 
@@ -140,8 +140,8 @@ By default, the routing configuration file in a Symfony application is
 located at ``app/config/routing.yml``. Like all configuration in Symfony,
 you can also choose to use XML or PHP out of the box to configure routes.
 
-If you look at the main routing file, you'll see that Symfony already added
-an entry when you generated the ``AcmeDemoBundle``:
+If you look at the main routing file, you'll see that Symfony already added an
+entry when you generated the AcmeDemoBundle:
 
 .. configuration-block::
 
@@ -181,9 +181,10 @@ an entry when you generated the ``AcmeDemoBundle``:
 
 This entry is pretty basic: it tells Symfony to load routing configuration
 from the ``Resources/config/routing.yml`` (``routing.xml`` or ``routing.php``
-in the XML and PHP code example respectively) file that lives inside the ``AcmeDemoBundle``.
-This means that you place routing configuration directly in ``app/config/routing.yml``
-or organize your routes throughout your application, and import them from here.
+in the XML and PHP code example respectively) file that lives inside the
+AcmeDemoBundle. This means that you place routing configuration directly in
+``app/config/routing.yml`` or organize your routes throughout your application,
+and import them from here.
 
 .. note::
 
@@ -255,7 +256,7 @@ that controller.
 The controller - ``AcmeDemoBundle:Random:index`` is the *logical* name of
 the controller, and it maps to the ``indexAction`` method of a PHP class
 called ``Acme\DemoBundle\Controller\RandomController``. Start by creating this
-file inside your ``AcmeDemoBundle``::
+file inside your AcmeDemoBundle::
 
     // src/Acme/DemoBundle/Controller/RandomController.php
     namespace Acme\DemoBundle\Controller;
@@ -388,7 +389,7 @@ location using the following convention.
 
     **/path/to/BundleName**/Resources/views/**ControllerName**/**TemplateName**
 
-In this case, ``AcmeDemoBundle`` is the bundle name, ``Random`` is the
+In this case, AcmeDemoBundle is the bundle name, ``Random`` is the
 controller, and ``index.html.twig`` the template:
 
 .. configuration-block::
@@ -636,7 +637,7 @@ in your application and to optimize them the way you want.
    to the organization and best practices of :doc:`bundles </cookbook/bundles/best_practices>`.
 
 A bundle is simply a structured set of files within a directory that implement
-a single feature. You might create a ``BlogBundle``, a ``ForumBundle`` or
+a single feature. You might create a BlogBundle, a ForumBundle or
 a bundle for user management (many of these exist already as open source
 bundles). Each directory contains everything related to that feature, including
 PHP files, templates, stylesheets, JavaScripts, tests and anything else.
@@ -685,13 +686,13 @@ The Symfony Standard Edition comes with a handy task that creates a fully-functi
 bundle for you. Of course, creating a bundle by hand is pretty easy as well.
 
 To show you how simple the bundle system is, create a new bundle called
-``AcmeTestBundle`` and enable it.
+AcmeTestBundle and enable it.
 
 .. tip::
 
     The ``Acme`` portion is just a dummy name that should be replaced by
-    some "vendor" name that represents you or your organization (e.g. ``ABCTestBundle``
-    for some company named ``ABC``).
+    some "vendor" name that represents you or your organization (e.g.
+    ABCTestBundle for some company named ``ABC``).
 
 Start by creating a ``src/Acme/TestBundle/`` directory and adding a new file
 called ``AcmeTestBundle.php``::
@@ -707,9 +708,10 @@ called ``AcmeTestBundle.php``::
 
 .. tip::
 
-   The name ``AcmeTestBundle`` follows the standard :ref:`Bundle naming conventions <bundles-naming-conventions>`.
-   You could also choose to shorten the name of the bundle to simply ``TestBundle``
-   by naming this class ``TestBundle`` (and naming the file ``TestBundle.php``).
+   The name AcmeTestBundle follows the standard
+   :ref:`Bundle naming conventions <bundles-naming-conventions>`. You could
+   also choose to shorten the name of the bundle to simply TestBundle by naming
+   this class TestBundle (and naming the file ``TestBundle.php``).
 
 This empty class is the only piece you need to create the new bundle. Though
 commonly empty, this class is powerful and can be used to customize the behavior
@@ -730,8 +732,7 @@ Now that you've created the bundle, enable it via the ``AppKernel`` class::
         return $bundles;
     }
 
-And while it doesn't do anything yet, ``AcmeTestBundle`` is now ready to
-be used.
+And while it doesn't do anything yet, AcmeTestBundle is now ready to be used.
 
 And as easy as this is, Symfony also provides a command-line interface for
 generating a basic bundle skeleton:
@@ -755,8 +756,8 @@ Bundle Directory Structure
 
 The directory structure of a bundle is simple and flexible. By default, the
 bundle system follows a set of conventions that help to keep code consistent
-between all Symfony bundles. Take a look at ``AcmeDemoBundle``, as it contains
-some of the most common elements of a bundle:
+between all Symfony bundles. Take a look at AcmeDemoBundle, as it contains some
+of the most common elements of a bundle:
 
 ``Controller/``
     Contains the controllers of the bundle (e.g. ``RandomController.php``).

book/propel.rst

@@ -18,7 +18,7 @@ persist it to the database and fetch it back out.
 .. sidebar:: Code along with the Example
 
     If you want to follow along with the example in this chapter, create an
-    ``AcmeStoreBundle`` via:
+    AcmeStoreBundle via:
 
     .. code-block:: bash
 
@@ -86,7 +86,7 @@ generated by Propel contain some business logic.
 
 Suppose you're building an application where products need to be displayed.
 First, create a ``schema.xml`` file inside the ``Resources/config`` directory
-of your ``AcmeStoreBundle``:
+of your AcmeStoreBundle:
 
 .. code-block:: xml
 
@@ -129,7 +129,7 @@ After creating your ``schema.xml``, generate your model from it by running:
     $ php app/console propel:model:build
 
 This generates each model class to quickly develop your application in the
-``Model/`` directory of the ``AcmeStoreBundle`` bundle.
+``Model/`` directory of the AcmeStoreBundle bundle.
 
 Creating the Database Tables/Schema
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

book/service_container.rst

@@ -333,12 +333,12 @@ Importing Configuration with ``imports``
 
 So far, you've placed your ``my_mailer`` service container definition directly
 in the application configuration file (e.g. ``app/config/config.yml``). Of
-course, since the ``Mailer`` class itself lives inside the ``AcmeHelloBundle``,
-it makes more sense to put the ``my_mailer`` container definition inside the
+course, since the ``Mailer`` class itself lives inside the AcmeHelloBundle, it
+makes more sense to put the ``my_mailer`` container definition inside the
 bundle as well.
 
 First, move the ``my_mailer`` container definition into a new container resource
-file inside ``AcmeHelloBundle``. If the ``Resources`` or ``Resources/config``
+file inside AcmeHelloBundle. If the ``Resources`` or ``Resources/config``
 directories don't exist, create them.
 
 .. configuration-block::
@@ -423,10 +423,9 @@ configuration.
 The ``imports`` directive allows your application to include service container
 configuration resources from any other location (most commonly from bundles).
 The ``resource`` location, for files, is the absolute path to the resource
-file. The special ``@AcmeHello`` syntax resolves the directory path of
-the ``AcmeHelloBundle`` bundle. This helps you specify the path to the resource
-without worrying later if you move the ``AcmeHelloBundle`` to a different
-directory.
+file. The special ``@AcmeHello`` syntax resolves the directory path of the
+AcmeHelloBundle bundle. This helps you specify the path to the resource without
+worrying later if you move the AcmeHelloBundle to a different directory.
 
 .. index::
    single: Service Container; Extension configuration

book/templating.rst

@@ -415,27 +415,27 @@ templates, each which lives in a specific location:
   template for a specific page. The three parts of the string, each separated
   by a colon (``:``), mean the following:
 
-  * ``AcmeBlogBundle``: (*bundle*) the template lives inside the
-    ``AcmeBlogBundle`` (e.g. ``src/Acme/BlogBundle``);
+  * ``AcmeBlogBundle``: (*bundle*) the template lives inside the AcmeBlogBundle
+    (e.g. ``src/Acme/BlogBundle``);
 
   * ``Blog``: (*directory*) indicates that the template lives inside the
     ``Blog`` subdirectory of ``Resources/views``;
 
   * ``index.html.twig``: (*filename*) the actual name of the file is
     ``index.html.twig``.
 
-  Assuming that the ``AcmeBlogBundle`` lives at ``src/Acme/BlogBundle``, the
+  Assuming that the AcmeBlogBundle lives at ``src/Acme/BlogBundle``, the
   final path to the layout would be ``src/Acme/BlogBundle/Resources/views/Blog/index.html.twig``.
 
 * ``AcmeBlogBundle::layout.html.twig``: This syntax refers to a base template
-  that's specific to the ``AcmeBlogBundle``. Since the middle, "directory",
-  portion is missing (e.g. ``Blog``), the template lives at
-  ``Resources/views/layout.html.twig`` inside ``AcmeBlogBundle``.
-  Yes, there are 2 colons in the middle of the string when the "controller"
-  subdirectory part is missing.
+  that's specific to the AcmeBlogBundle. Since the middle, "directory", portion
+  is missing (e.g. ``Blog``), the template lives at
+  ``Resources/views/layout.html.twig`` inside AcmeBlogBundle. Yes, there are 2
+  colons in the middle of the string when the "controller" subdirectory part is
+  missing.
 
 In the :ref:`overriding-bundle-templates` section, you'll find out how each
-template living inside the ``AcmeBlogBundle``, for example, can be overridden
+template living inside the AcmeBlogBundle, for example, can be overridden
 by placing a template of the same name in the ``app/Resources/AcmeBlogBundle/views/``
 directory. This gives the power to override templates from any vendor bundle.
 
@@ -1247,10 +1247,10 @@ bundles (see `KnpBundles.com`_) for a large number of different features.
 Once you use a third-party bundle, you'll likely need to override and customize
 one or more of its templates.
 
-Suppose you've installed the imaginary open-source ``AcmeBlogBundle`` in your
+Suppose you've installed the imaginary open-source AcmeBlogBundle in your
 project. And while you're really happy with everything, you want to override
 the blog "list" page to customize the markup specifically for your application.
-By digging into the ``Blog`` controller of the ``AcmeBlogBundle``, you find the
+By digging into the ``Blog`` controller of the AcmeBlogBundle, you find the
 following::
 
     public function indexAction()
@@ -1281,7 +1281,7 @@ to create it). You're now free to customize the template.
     cache (``php app/console cache:clear``), even if you are in debug mode.
 
 This logic also applies to base bundle templates. Suppose also that each
-template in ``AcmeBlogBundle`` inherits from a base template called
+template in AcmeBlogBundle inherits from a base template called
 ``AcmeBlogBundle::layout.html.twig``. Just as before, Symfony will look in
 the following two places for the template:
 

components/console/helpers/dialoghelper.rst

@@ -54,7 +54,7 @@ if you want to know a bundle name, you can add this to your command::
 The user will be asked "Please enter the name of the bundle". They can type
 some name which will be returned by the
 :method:`Symfony\\Component\\Console\\Helper\\DialogHelper::ask` method.
-If they leave it empty, the default value (``AcmeDemoBundle`` here) is returned.
+If they leave it empty, the default value (AcmeDemoBundle here) is returned.
 
 Autocompletion
 ~~~~~~~~~~~~~~

cookbook/assetic/asset_management.rst

@@ -92,7 +92,7 @@ To include JavaScript files, use the ``javascripts`` tag in any template:
     You can also include CSS Stylesheets: see :ref:`cookbook-assetic-including-css`.
 
 In this example, all of the files in the ``Resources/public/js/`` directory
-of the ``AppBundle`` will be loaded and served from a different location.
+of the AppBundle will be loaded and served from a different location.
 The actual rendered tag might simply look like:
 
 .. code-block:: html

cookbook/assetic/uglifyjs.rst

@@ -176,9 +176,9 @@ your assets are a part of the view layer, this work is done in your templates:
 
 .. note::
 
-    The above example assumes that you have a bundle called ``AppBundle``
-    and your JavaScript files are in the ``Resources/public/js`` directory under
-    your bundle. This isn't important however - you can include your JavaScript
+    The above example assumes that you have a bundle called AppBundle and your
+    JavaScript files are in the ``Resources/public/js`` directory under your
+    bundle. This isn't important however - you can include your JavaScript
     files no matter where they are.
 
 With the addition of the ``uglifyjs2`` filter to the asset tags above, you

cookbook/assetic/yuicompressor.rst

@@ -106,9 +106,9 @@ the view layer, this work is done in your templates:
 
 .. note::
 
-    The above example assumes that you have a bundle called ``AppBundle``
-    and your JavaScript files are in the ``Resources/public/js`` directory under
-    your bundle. This isn't important however - you can include your JavaScript
+    The above example assumes that you have a bundle called AppBundle and your
+    JavaScript files are in the ``Resources/public/js`` directory under your
+    bundle. This isn't important however - you can include your JavaScript
     files no matter where they are.
 
 With the addition of the ``yui_js`` filter to the asset tags above, you should