feature #8579 Migrating Best Practices topics to Symfony Flex structure (yceruto)

This PR was merged into the master branch.

Discussion
----------

Migrating Best Practices topics to Symfony Flex structure

Pending files for other PR:
* configuration.rst
* creating-the-project.rst
* i18n.rst
* templates.rst

Commits
-------

176bbdf [Best Practices] More changes of Symfony Flex structure

Author: weaverryan

best_practices/controllers.rst

@@ -41,32 +41,30 @@ configuration to the main routing configuration file:
 
 .. code-block:: yaml
 
-    # app/config/routing.yml
-    app:
-        resource: '@AppBundle/Controller/'
+    # config/routes.yaml
+    controllers:
+        resource: '../src/Controller/'
         type:     annotation
 
 This configuration will load annotations from any controller stored inside the
-``src/AppBundle/Controller/`` directory and even from its subdirectories.
-So if your application defines lots of controllers, it's perfectly ok to
-reorganize them into subdirectories:
+``src/Controller/`` directory and even from its subdirectories. So if your application
+defines lots of controllers, it's perfectly ok to reorganize them into subdirectories:
 
 .. code-block:: text
 
     <your-project>/
     ├─ ...
     └─ src/
-       └─ AppBundle/
+       ├─ ...
+       └─ Controller/
+          ├─ DefaultController.php
           ├─ ...
-          └─ Controller/
-             ├─ DefaultController.php
+          ├─ Api/
+          │  ├─ ...
+          │  └─ ...
+          └─ Backend/
              ├─ ...
-             ├─ Api/
-             │  ├─ ...
-             │  └─ ...
-             └─ Backend/
-                ├─ ...
-                └─ ...
+             └─ ...
 
 Template Configuration
 ----------------------
@@ -93,9 +91,9 @@ for the homepage of our app:
 
 .. code-block:: php
 
-    namespace AppBundle\Controller;
+    namespace App\Controller;
 
-    use AppBundle\Entity\Post;
+    use App\Entity\Post;
     use Symfony\Bundle\FrameworkBundle\Controller\Controller;
     use Symfony\Component\Routing\Annotation\Route;
 
@@ -111,7 +109,7 @@ for the homepage of our app:
                 ->findLatest();
 
             return $this->render('default/index.html.twig', array(
-                'posts' => $posts
+                'posts' => $posts,
             ));
         }
     }
@@ -149,7 +147,7 @@ For example:
 
 .. code-block:: php
 
-    use AppBundle\Entity\Post;
+    use App\Entity\Post;
     use Symfony\Component\Routing\Annotation\Route;
 
     /**
@@ -160,7 +158,7 @@ For example:
         $deleteForm = $this->createDeleteForm($post);
 
         return $this->render('admin/post/show.html.twig', array(
-            'post'        => $post,
+            'post' => $post,
             'delete_form' => $deleteForm->createView(),
         ));
     }
@@ -202,7 +200,7 @@ flexible:
 
 .. code-block:: php
 
-    use AppBundle\Entity\Post;
+    use App\Entity\Post;
     use Sensio\Bundle\FrameworkExtraBundle\Configuration\ParamConverter;
     use Symfony\Component\HttpFoundation\Request;
     use Symfony\Component\Routing\Annotation\Route;

best_practices/forms.rst

@@ -17,9 +17,9 @@ code. This is perfectly fine if you don't need to reuse the form somewhere else.
 But for organization and reuse, we recommend that you define each
 form in its own PHP class::
 
-    namespace AppBundle\Form;
+    namespace App\Form;
 
-    use AppBundle\Entity\Post;
+    use App\Entity\Post;
     use Symfony\Component\Form\AbstractType;
     use Symfony\Component\Form\FormBuilderInterface;
     use Symfony\Component\OptionsResolver\OptionsResolver;
@@ -50,13 +50,13 @@ form in its own PHP class::
 
 .. best-practice::
 
-    Put the form type classes in the ``AppBundle\Form`` namespace, unless you
+    Put the form type classes in the ``App\Form`` namespace, unless you
     use other custom form classes like data transformers.
 
 To use the class, use ``createForm()`` and pass the fully qualified class name::
 
     // ...
-    use AppBundle\Form\PostType;
+    use App\Form\PostType;
 
     // ...
     public function newAction(Request $request)
@@ -109,13 +109,13 @@ This form *may* have been designed for creating posts, but if you wanted
 to reuse it for editing posts, the button label would be wrong. Instead,
 some developers configure form buttons in the controller::
 
-    namespace AppBundle\Controller\Admin;
+    namespace App\Controller\Admin;
 
+    use App\Entity\Post;
+    use App\Form\PostType;
     use Symfony\Component\HttpFoundation\Request;
     use Symfony\Bundle\FrameworkBundle\Controller\Controller;
     use Symfony\Component\Form\Extension\Core\Type\SubmitType;
-    use AppBundle\Entity\Post;
-    use AppBundle\Form\PostType;
 
     class PostController extends Controller
     {
@@ -127,7 +127,7 @@ some developers configure form buttons in the controller::
             $form = $this->createForm(PostType::class, $post);
             $form->add('submit', SubmitType::class, array(
                 'label' => 'Create',
-                'attr'  => array('class' => 'btn btn-default pull-right')
+                'attr' => array('class' => 'btn btn-default pull-right'),
             ));
 
             // ...

best_practices/security.rst

@@ -9,7 +9,7 @@ want and to load user information from any source. This is a complex topic, but
 the :doc:`Security guide</security>` has a lot of information about
 this.
 
-Regardless of your needs, authentication is configured in ``security.yml``,
+Regardless of your needs, authentication is configured in ``security.yaml``,
 primarily under the ``firewalls`` key.
 
 .. best-practice::
@@ -43,14 +43,14 @@ which uses a login form to load users from the database:
 
 .. code-block:: yaml
 
-    # app/config/security.yml
+    # config/packages/security.yaml
     security:
         encoders:
-            AppBundle\Entity\User: bcrypt
+            App\Entity\User: bcrypt
 
         providers:
             database_users:
-                entity: { class: AppBundle:User, property: username }
+                entity: { class: App:User, property: username }
 
         firewalls:
             secured_area:
@@ -74,7 +74,7 @@ Authorization (i.e. Denying Access)
 -----------------------------------
 
 Symfony gives you several ways to enforce authorization, including the ``access_control``
-configuration in :doc:`security.yml </reference/configuration/security>`, the
+configuration in :doc:`security.yaml </reference/configuration/security>`, the
 :ref:`@Security annotation <best-practices-security-annotation>` and using
 :ref:`isGranted <best-practices-directly-isGranted>` on the ``security.authorization_checker``
 service directly.
@@ -134,7 +134,7 @@ method on the ``Post`` object:
 
 .. code-block:: php
 
-    use AppBundle\Entity\Post;
+    use App\Entity\Post;
     use Sensio\Bundle\FrameworkExtraBundle\Configuration\Security;
     use Symfony\Component\Routing\Annotation\Route;
 
@@ -167,7 +167,7 @@ to the ``Post`` entity that checks if a given user is its author:
 
 .. code-block:: php
 
-    // src/AppBundle/Entity/Post.php
+    // src/Entity/Post.php
     // ...
 
     class Post
@@ -189,7 +189,7 @@ Now you can reuse this method both in the template and in the security expressio
 
 .. code-block:: php
 
-    use AppBundle\Entity\Post;
+    use App\Entity\Post;
     use Sensio\Bundle\FrameworkExtraBundle\Configuration\Security;
     use Symfony\Component\Routing\Annotation\Route;
 
@@ -263,13 +263,13 @@ the same ``getAuthorEmail()`` logic you used above:
 
 .. code-block:: php
 
-    namespace AppBundle\Security;
+    namespace App\Security;
 
+    use App\Entity\Post;
     use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
     use Symfony\Component\Security\Core\Authorization\AccessDecisionManagerInterface;
     use Symfony\Component\Security\Core\Authorization\Voter\Voter;
     use Symfony\Component\Security\Core\User\UserInterface;
-    use AppBundle\Entity\Post;
 
     class PostVoter extends Voter
     {
@@ -330,7 +330,7 @@ the same ``getAuthorEmail()`` logic you used above:
         }
     }
 
-If you're using the :ref:`default services.yml configuration <service-container-services-load-example>`,
+If you're using the :ref:`default services.yaml configuration <service-container-services-load-example>`,
 your application will :ref:`autoconfigure <services-autoconfigure>` your security
 voter and inject an ``AccessDecisionManagerInterface`` instance into it thanks to
 :doc:`autowiring </service_container/autowiring>`.

best_practices/web-assets.rst

@@ -7,7 +7,7 @@ stored these assets in the ``Resources/public/`` directory of each bundle.
 
 .. best-practice::
 
-    Store your assets in the ``web/`` directory.
+    Store your assets in the ``public/`` directory.
 
 Scattering your web assets across tens of different bundles makes it more
 difficult to manage them. Your designers' lives will be much easier if all
@@ -28,7 +28,7 @@ much more concise:
 
 .. note::
 
-    Keep in mind that ``web/`` is a public directory and that anything stored
+    Keep in mind that ``public/`` is a public directory and that anything stored
     here will be publicly accessible, including all the original asset files
     (e.g. Sass, LESS and CoffeeScript files).