fixed markup

symfony · weaverryan · Jan 13, 2013 · Jan 12, 2013 · Jan 12, 2013 · Jan 12, 2013
commit abdcf9f7f4afa355a8fedd9921a42f73fc21fb76
diff --git a/cookbook/service_container/scopes.rst b/cookbook/service_container/scopes.rst
@@ -7,7 +7,7 @@ How to work with Scopes
 This entry is all about scopes, a somewhat advanced topic related to the
 :doc:`/book/service_container`. If you've ever gotten an error mentioning
 "scopes" when creating services, or need to create a service that depends
-on the `request` service, then this entry is for you.
+on the ``request`` service, then this entry is for you.
 
 Understanding Scopes
 --------------------
@@ -16,49 +16,49 @@ The scope of a service controls how long an instance of a service is used
 by the container. The Dependency Injection component provides two generic
 scopes:
 
-- `container` (the default one): The same instance is used each time you
+- ``container`` (the default one): The same instance is used each time you
   request it from this container.
 
-- `prototype`: A new instance is created each time you request the service.
+- ``prototype``: A new instance is created each time you request the service.
 
-The FrameworkBundle also defines a third scope: `request`. This scope is
+The FrameworkBundle also defines a third scope: ``request``. This scope is
 tied to the request, meaning a new instance is created for each subrequest
 and is unavailable outside the request (for instance in the CLI).
 
 Scopes add a constraint on the dependencies of a service: a service cannot
 depend on services from a narrower scope. For example, if you create a generic
-`my_foo` service, but try to inject the `request` component, you'll receive
+``my_foo`` service, but try to inject the ``request`` component, you'll receive
 a :class:`Symfony\\Component\\DependencyInjection\\Exception\\ScopeWideningInjectionException`
 when compiling the container. Read the sidebar below for more details.
 
 .. sidebar:: Scopes and Dependencies
 
-    Imagine you've configured a `my_mailer` service. You haven't configured
-    the scope of the service, so it defaults to `container`. In other words,
-    every time you ask the container for the `my_mailer` service, you get
+    Imagine you've configured a ``my_mailer`` service. You haven't configured
+    the scope of the service, so it defaults to ``container``. In other words,
+    every time you ask the container for the ``my_mailer`` service, you get
     the same object back. This is usually how you want your services to work.
 
-    Imagine, however, that you need the `request` service in your `my_mailer`
+    Imagine, however, that you need the ``request`` service in your ``my_mailer``
     service, maybe because you're reading the URL of the current request.
     So, you add it as a constructor argument. Let's look at why this presents
     a problem:
 
-    * When requesting `my_mailer`, an instance of `my_mailer` (let's call
-      it *MailerA*) is created and the `request` service (let's call it
+    * When requesting ``my_mailer``, an instance of ``my_mailer`` (let's call
+      it *MailerA*) is created and the ``request`` service (let's call it
       *RequestA*) is passed to it. Life is good!
 
     * You've now made a subrequest in Symfony, which is a fancy way of saying
-      that you've called, for example, the `{{ render(...) }}` Twig function,
-      which executes another controller. Internally, the old `request` service
+      that you've called, for example, the ``{{ render(...) }}`` Twig function,
+      which executes another controller. Internally, the old ``request`` service
       (*RequestA*) is actually replaced by a new request instance (*RequestB*).
       This happens in the background, and it's totally normal.
 
-    * In your embedded controller, you once again ask for the `my_mailer`
-      service. Since your service is in the `container` scope, the same
+    * In your embedded controller, you once again ask for the ``my_mailer``
+      service. Since your service is in the ``container`` scope, the same
       instance (*MailerA*) is just re-used. But here's the problem: the
       *MailerA* instance still contains the old *RequestA* object, which
       is now **not** the correct request object to have (*RequestB* is now
-      the current `request` service). This is subtle, but the mis-match could
+      the current ``request`` service). This is subtle, but the mis-match could
       cause major problems, which is why it's not allowed.
 
       So, that's the reason *why* scopes exist, and how they can cause
@@ -101,20 +101,20 @@ The scope of a service is set in the definition of the service:
             new Definition('Acme\HelloBundle\Mail\GreetingCardManager')
         )->setScope('request');
 
-If you don't specify the scope, it defaults to `container`, which is what
+If you don't specify the scope, it defaults to ``container``, which is what
 you want most of the time. Unless your service depends on another service
-that's scoped to a narrower scope (most commonly, the `request` service),
+that's scoped to a narrower scope (most commonly, the ``request`` service),
 you probably don't need to set the scope.
 
 Using a Service from a narrower Scope
 -------------------------------------
 
 If your service depends on a scoped service, the best solution is to put
 it in the same scope (or a narrower one). Usually, this means putting your
-new service in the `request` scope.
+new service in the ``request`` scope.
 
 But this is not always possible (for instance, a twig extension must be in
-the `container` scope as the Twig environment needs it as a dependency).
+the ``container`` scope as the Twig environment needs it as a dependency).
 In these cases, you should pass the entire container into your service and
 retrieve your dependency from the container each time you need it to be sure
 you have the right instance::