Permalink
Browse files

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
  • Loading branch information...
weaverryan committed Jan 25, 2015
2 parents a6b7d72 + f361c87 commit f5f3c1bfc1c131163b9e76082c50808e5be22330
@@ -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:
@@ -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.
@@ -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
@@ -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::
@@ -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;
@@ -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``).
@@ -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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -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
@@ -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:
@@ -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
~~~~~~~~~~~~~~
@@ -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
@@ -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
@@ -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
Oops, something went wrong.

0 comments on commit f5f3c1b

Please sign in to comment.