From f361c8771e20499cfac1353ff376896489cf8714 Mon Sep 17 00:00:00 2001 From: WouterJ Date: Sat, 17 Jan 2015 00:27:52 +0100 Subject: [PATCH] Removed literals for bundle names --- best_practices/business-logic.rst | 8 ++-- best_practices/controllers.rst | 4 +- best_practices/creating-the-project.rst | 22 +++++----- book/controller.rst | 10 ++--- book/doctrine.rst | 2 +- book/page_creation.rst | 41 ++++++++++--------- book/propel.rst | 6 +-- book/service_container.rst | 13 +++--- book/templating.rst | 24 +++++------ components/console/helpers/dialoghelper.rst | 2 +- cookbook/assetic/asset_management.rst | 2 +- cookbook/assetic/uglifyjs.rst | 6 +-- cookbook/assetic/yuicompressor.rst | 6 +-- cookbook/bundles/best_practices.rst | 3 +- cookbook/bundles/extension.rst | 4 +- cookbook/bundles/prepend_extension.rst | 6 +-- .../doctrine/multiple_entity_managers.rst | 6 +-- cookbook/doctrine/reverse_engineering.rst | 5 +-- cookbook/profiler/data_collector.rst | 2 +- cookbook/security/entity_provider.rst | 8 ++-- quick_tour/the_architecture.rst | 6 +-- reference/configuration/doctrine.rst | 2 +- reference/constraints/UniqueEntity.rst | 2 +- 23 files changed, 94 insertions(+), 96 deletions(-) diff --git a/best_practices/business-logic.rst b/best_practices/business-logic.rst index 3799e7c0f83..9ddb6c5aa00 100644 --- a/best_practices/business-logic.rst +++ b/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: diff --git a/best_practices/controllers.rst b/best_practices/controllers.rst index 31c4ae09438..a31db8e21c6 100644 --- a/best_practices/controllers.rst +++ b/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. diff --git a/best_practices/creating-the-project.rst b/best_practices/creating-the-project.rst index 42dca76c3da..d4eed5062f5 100644 --- a/best_practices/creating-the-project.rst +++ b/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 diff --git a/book/controller.rst b/book/controller.rst index c7cccc810db..c061ad8c063 100644 --- a/book/controller.rst +++ b/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:: diff --git a/book/doctrine.rst b/book/doctrine.rst index 0f3f62086d0..a4a96f5e125 100644 --- a/book/doctrine.rst +++ b/book/doctrine.rst @@ -193,7 +193,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; diff --git a/book/page_creation.rst b/book/page_creation.rst index ac23536b46c..3d050051612 100644 --- a/book/page_creation.rst +++ b/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 `. 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 `. - 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 `. 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``). diff --git a/book/propel.rst b/book/propel.rst index 7d5f919593e..9ff589afb04 100644 --- a/book/propel.rst +++ b/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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/book/service_container.rst b/book/service_container.rst index fef11d05fda..226271375cb 100644 --- a/book/service_container.rst +++ b/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 diff --git a/book/templating.rst b/book/templating.rst index 4b003e8bad6..0e00d61581f 100644 --- a/book/templating.rst +++ b/book/templating.rst @@ -415,8 +415,8 @@ 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``; @@ -424,18 +424,18 @@ templates, each which lives in a specific location: * ``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: diff --git a/components/console/helpers/dialoghelper.rst b/components/console/helpers/dialoghelper.rst index 96c5c880d09..3ec20a601bd 100644 --- a/components/console/helpers/dialoghelper.rst +++ b/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 ~~~~~~~~~~~~~~ diff --git a/cookbook/assetic/asset_management.rst b/cookbook/assetic/asset_management.rst index 785e239b1a0..278635ebf38 100644 --- a/cookbook/assetic/asset_management.rst +++ b/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 diff --git a/cookbook/assetic/uglifyjs.rst b/cookbook/assetic/uglifyjs.rst index a028c50e7b7..8b0ddd66028 100644 --- a/cookbook/assetic/uglifyjs.rst +++ b/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 diff --git a/cookbook/assetic/yuicompressor.rst b/cookbook/assetic/yuicompressor.rst index 7e3671fa2fb..356b67b6071 100644 --- a/cookbook/assetic/yuicompressor.rst +++ b/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 diff --git a/cookbook/bundles/best_practices.rst b/cookbook/bundles/best_practices.rst index 21947295b08..c580a46674a 100644 --- a/cookbook/bundles/best_practices.rst +++ b/cookbook/bundles/best_practices.rst @@ -80,8 +80,7 @@ examples). Directory Structure ------------------- -The basic directory structure of a ``HelloBundle`` bundle must read as -follows: +The basic directory structure of a HelloBundle must read as follows: .. code-block:: text diff --git a/cookbook/bundles/extension.rst b/cookbook/bundles/extension.rst index bdaf74570a6..aa2c5be8a35 100644 --- a/cookbook/bundles/extension.rst +++ b/cookbook/bundles/extension.rst @@ -23,8 +23,8 @@ following conventions: * It has to live in the ``DependencyInjection`` namespace of the bundle; * The name is equal to the bundle name with the ``Bundle`` suffix replaced by - ``Extension`` (e.g. the Extension class of ``AppBundle`` would be called - ``AppExtension`` and the one for ``AcmeHelloBundle`` would be called + ``Extension`` (e.g. the Extension class of the AppBundle would be called + ``AppExtension`` and the one for AcmeHelloBundle would be called ``AcmeHelloExtension``). The Extension class should implement the diff --git a/cookbook/bundles/prepend_extension.rst b/cookbook/bundles/prepend_extension.rst index 4c5cb7364fc..06e93990e6f 100644 --- a/cookbook/bundles/prepend_extension.rst +++ b/cookbook/bundles/prepend_extension.rst @@ -90,9 +90,9 @@ in case a specific other bundle is not registered:: } } -The above would be the equivalent of writing the following into the ``app/config/config.yml`` -in case ``AcmeGoodbyeBundle`` is not registered and the ``entity_manager_name`` setting -for ``acme_hello`` is set to ``non_default``: +The above would be the equivalent of writing the following into the +``app/config/config.yml`` in case AcmeGoodbyeBundle is not registered and the +``entity_manager_name`` setting for ``acme_hello`` is set to ``non_default``: .. configuration-block:: diff --git a/cookbook/doctrine/multiple_entity_managers.rst b/cookbook/doctrine/multiple_entity_managers.rst index ce2a3f685c6..5434d847365 100644 --- a/cookbook/doctrine/multiple_entity_managers.rst +++ b/cookbook/doctrine/multiple_entity_managers.rst @@ -150,9 +150,9 @@ The following configuration code shows how you can configure two entity managers In this case, you've defined two entity managers and called them ``default`` and ``customer``. The ``default`` entity manager manages entities in the -``AppBundle`` and ``AcmeStoreBundle``, while the ``customer`` entity -manager manages entities in the ``AcmeCustomerBundle``. You've also defined -two connections, one for each entity manager. +AppBundle and AcmeStoreBundle, while the ``customer`` entity manager manages +entities in the AcmeCustomerBundle. You've also defined two connections, one +for each entity manager. .. note:: diff --git a/cookbook/doctrine/reverse_engineering.rst b/cookbook/doctrine/reverse_engineering.rst index b5078d4aa44..dd50a6be9c2 100644 --- a/cookbook/doctrine/reverse_engineering.rst +++ b/cookbook/doctrine/reverse_engineering.rst @@ -49,9 +49,8 @@ to a post record thanks to a foreign key constraint. Before diving into the recipe, be sure your database connection parameters are correctly setup in the ``app/config/parameters.yml`` file (or wherever your database configuration is kept) and that you have initialized a bundle that -will host your future entity class. In this tutorial it's assumed that -an ``AcmeBlogBundle`` exists and is located under the ``src/Acme/BlogBundle`` -folder. +will host your future entity class. In this tutorial it's assumed that an +AcmeBlogBundle exists and is located under the ``src/Acme/BlogBundle`` folder. The first step towards building entity classes from an existing database is to ask Doctrine to introspect the database and generate the corresponding diff --git a/cookbook/profiler/data_collector.rst b/cookbook/profiler/data_collector.rst index 6c02639f197..db3a86bfdab 100644 --- a/cookbook/profiler/data_collector.rst +++ b/cookbook/profiler/data_collector.rst @@ -152,7 +152,7 @@ All blocks have access to the ``collector`` object. To enable the template, add a ``template`` attribute to the ``data_collector`` tag in your configuration. For example, assuming your template is in some -``AcmeDebugBundle``: +AcmeDebugBundle: .. configuration-block:: diff --git a/cookbook/security/entity_provider.rst b/cookbook/security/entity_provider.rst index 144d7809f48..98df1da6a69 100644 --- a/cookbook/security/entity_provider.rst +++ b/cookbook/security/entity_provider.rst @@ -37,10 +37,10 @@ retrieve users from a database with custom conditions. The Data Model -------------- -For the purpose of this cookbook, the ``AcmeUserBundle`` bundle contains a -``User`` entity class with the following fields: ``id``, ``username``, -``password``, ``email`` and ``isActive``. The ``isActive`` field tells whether -or not the user account is active. +For the purpose of this cookbook, the AcmeUserBundle bundle contains a ``User`` +entity class with the following fields: ``id``, ``username``, ``password``, +``email`` and ``isActive``. The ``isActive`` field tells whether or not the +user account is active. To make it shorter, the getter and setter methods for each have been removed to focus on the most important methods that come from the diff --git a/quick_tour/the_architecture.rst b/quick_tour/the_architecture.rst index f8e947dae75..aa644328799 100644 --- a/quick_tour/the_architecture.rst +++ b/quick_tour/the_architecture.rst @@ -90,8 +90,8 @@ own bundles. It makes it easy to pick and choose which features to enable in your application and optimize them the way you want. And at the end of the day, your application code is just as *important* as the core framework itself. -Symfony already includes an ``AppBundle`` that you may use to start developing -your application. Then, if you need to split the application into reusable +Symfony already includes an AppBundle that you may use to start developing your +application. Then, if you need to split the application into reusable components, you can create your own bundles. Registering a Bundle @@ -99,7 +99,7 @@ Registering a Bundle An application is made up of bundles as defined in the ``registerBundles()`` method of the ``AppKernel`` class. Each bundle is a directory that contains -a single ``Bundle`` class that describes it:: +a single Bundle class that describes it:: // app/AppKernel.php public function registerBundles() diff --git a/reference/configuration/doctrine.rst b/reference/configuration/doctrine.rst index 5a7afc42dca..d11044e632a 100644 --- a/reference/configuration/doctrine.rst +++ b/reference/configuration/doctrine.rst @@ -336,7 +336,7 @@ A common namespace prefix that all entities of this mapping share. This prefix should never conflict with prefixes of other defined mappings otherwise some of your entities cannot be found by Doctrine. This option defaults to the bundle namespace + ``Entity``, for example for an application bundle called -``AcmeHelloBundle`` prefix would be ``Acme\HelloBundle\Entity``. +AcmeHelloBundle prefix would be ``Acme\HelloBundle\Entity``. alias ..... diff --git a/reference/constraints/UniqueEntity.rst b/reference/constraints/UniqueEntity.rst index 98be847645f..c2dd5e0f439 100644 --- a/reference/constraints/UniqueEntity.rst +++ b/reference/constraints/UniqueEntity.rst @@ -23,7 +23,7 @@ using an email address that already exists in the system. Basic Usage ----------- -Suppose you have an ``AcmeUserBundle`` bundle with a ``User`` entity that has an +Suppose you have an AcmeUserBundle bundle with a ``User`` entity that has an ``email`` field. You can use the ``UniqueEntity`` constraint to guarantee that the ``email`` field remains unique between all of the constraints in your user table: