From 1c05aadef8021d624c81489456ab098a292b2eb8 Mon Sep 17 00:00:00 2001 From: WouterJ Date: Mon, 29 Jun 2015 11:52:29 +0200 Subject: [PATCH] Removed the glossary --- book/from_flat_php_to_symfony2.rst | 10 +-- book/http_cache.rst | 11 +-- book/http_fundamentals.rst | 8 +- book/service_container.rst | 18 ++-- book/translation.rst | 6 +- components/form/introduction.rst | 10 ++- cookbook/symfony1.rst | 5 -- glossary.rst | 136 ----------------------------- quick_tour/the_architecture.rst | 15 ++-- quick_tour/the_big_picture.rst | 8 +- reference/constraints/Callback.rst | 2 +- 11 files changed, 46 insertions(+), 183 deletions(-) delete mode 100644 glossary.rst diff --git a/book/from_flat_php_to_symfony2.rst b/book/from_flat_php_to_symfony2.rst index 14362f9cd06..87ce00b48fa 100644 --- a/book/from_flat_php_to_symfony2.rst +++ b/book/from_flat_php_to_symfony2.rst @@ -123,9 +123,9 @@ is primarily an HTML file that uses a template-like PHP syntax: By convention, the file that contains all the application logic - ``index.php`` - -is known as a "controller". The term :term:`controller` is a word you'll hear -a lot, regardless of the language or framework you use. It refers simply -to the area of *your* code that processes user input and prepares the response. +is known as a "controller". The term controller is a word you'll hear a lot, +regardless of the language or framework you use. It refers simply to the area +of *your* code that processes user input and prepares the response. In this case, the controller prepares data from the database and then includes a template to present that data. With the controller isolated, you could @@ -312,8 +312,8 @@ to security... A "Front Controller" to the Rescue ---------------------------------- -The solution is to use a :term:`front controller`: a single PHP file through -which *all* requests are processed. With a front controller, the URIs for the +The solution is to use a front controller: a single PHP file through which +*all* requests are processed. With a front controller, the URIs for the application change slightly, but start to become more flexible: .. code-block:: text diff --git a/book/http_cache.rst b/book/http_cache.rst index d21f611fbd4..a433d2a3b6d 100644 --- a/book/http_cache.rst +++ b/book/http_cache.rst @@ -26,11 +26,11 @@ websites, or is it? In this chapter, you'll see how the Symfony cache system works and why this is the best possible approach. The Symfony cache system is different because it relies on the simplicity -and power of the HTTP cache as defined in the :term:`HTTP specification`. -Instead of reinventing a caching methodology, Symfony embraces the standard -that defines basic communication on the Web. Once you understand the fundamental -HTTP validation and expiration caching models, you'll be ready to master -the Symfony cache system. +and power of the HTTP cache as defined in the `HTTP specification`_. Instead of +reinventing a caching methodology, Symfony embraces the standard that defines +basic communication on the Web. Once you understand the fundamental HTTP +validation and expiration caching models, you'll be ready to master the Symfony +cache system. For the purposes of learning how to cache with Symfony, the subject is covered in four steps: @@ -1260,3 +1260,4 @@ Learn more from the Cookbook .. _`FrameworkExtraBundle documentation`: https://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/cache.html .. _`ESI`: http://www.w3.org/TR/esi-lang .. _`FOSHttpCacheBundle`: http://foshttpcachebundle.readthedocs.org/ +.. _`HTTP specification`: http://www.w3.org/Protocols/rfc2616/rfc2616.html diff --git a/book/http_fundamentals.rst b/book/http_fundamentals.rst index 97c9e346323..86719d46251 100644 --- a/book/http_fundamentals.rst +++ b/book/http_fundamentals.rst @@ -334,8 +334,8 @@ breaking all of your links?) and the fact that each file *must* manually include some set of core files so that security, database connections and the "look" of the site can remain consistent. -A much better solution is to use a :term:`front controller`: a single PHP -file that handles every request coming into your application. For example: +A much better solution is to use a front controller: a single PHP file that +handles every request coming into your application. For example: +------------------------+------------------------+ | ``/index.php`` | executes ``index.php`` | @@ -401,8 +401,8 @@ the same simple pattern for every request: Each "page" of your site is defined in a routing configuration file that maps different URLs to different PHP functions. The job of each PHP function, -called a :term:`controller`, is to use information from the request - along -with many other tools Symfony makes available - to create and return a ``Response`` +called a controller, is to use information from the request - along with many +other tools Symfony makes available - to create and return a ``Response`` object. In other words, the controller is where *your* code goes: it's where you interpret the request and create a response. diff --git a/book/service_container.rst b/book/service_container.rst index 32854aa4c7f..66176a97228 100644 --- a/book/service_container.rst +++ b/book/service_container.rst @@ -39,13 +39,13 @@ the service container makes writing good code so easy. What is a Service? ------------------ -Put simply, a :term:`Service` is any PHP object that performs some sort of -"global" task. It's a purposefully-generic name used in computer science -to describe an object that's created for a specific purpose (e.g. delivering -emails). Each service is used throughout your application whenever you need -the specific functionality it provides. You don't have to do anything special -to make a service: simply write a PHP class with some code that accomplishes -a specific task. Congratulations, you've just created a service! +Put simply, a service is any PHP object that performs some sort of "global" +task. It's a purposefully-generic name used in computer science to describe an +object that's created for a specific purpose (e.g. delivering emails). Each +service is used throughout your application whenever you need the specific +functionality it provides. You don't have to do anything special to make a +service: simply write a PHP class with some code that accomplishes a specific +task. Congratulations, you've just created a service! .. note:: @@ -72,8 +72,8 @@ are key to being a good developer in almost any language. What is a Service Container? ---------------------------- -A :term:`Service Container` (or *dependency injection container*) is simply -a PHP object that manages the instantiation of services (i.e. objects). +A service container (or *dependency injection container*) is simply a PHP +object that manages the instantiation of services (i.e. objects). For example, suppose you have a simple PHP class that delivers email messages. Without a service container, you must manually create the object whenever diff --git a/book/translation.rst b/book/translation.rst index 2dad6445553..7ea2cdc28ab 100644 --- a/book/translation.rst +++ b/book/translation.rst @@ -51,9 +51,9 @@ to learn even more. Overall, the process has several steps: Configuration ------------- -Translations are handled by a ``translator`` :term:`service` that uses the -user's locale to lookup and return translated messages. Before using it, -enable the ``translator`` in your configuration: +Translations are handled by a ``translator`` service that uses the user's +locale to lookup and return translated messages. Before using it, enable the +``translator`` in your configuration: .. configuration-block:: diff --git a/components/form/introduction.rst b/components/form/introduction.rst index 4b5028bf183..a0b623bc443 100644 --- a/components/form/introduction.rst +++ b/components/form/introduction.rst @@ -362,10 +362,12 @@ and then access it whenever you need to build a form. this object in some more "global" way so you can access it from anywhere. Exactly how you gain access to your one form factory is up to you. If you're -using a :term:`Service Container`, then you should add the form factory to -your container and grab it out whenever you need to. If your application -uses global or static variables (not usually a good idea), then you can store -the object on some static class or do something similar. +using a service container (like provided with the +:doc:`DependencyInjection component `), +then you should add the form factory to your container and grab it out whenever +you need to. If your application uses global or static variables (not usually a +good idea), then you can store the object on some static class or do something +similar. Regardless of how you architect your application, just remember that you should only have one form factory and that you'll need to be able to access diff --git a/cookbook/symfony1.rst b/cookbook/symfony1.rst index 1ae0dd07293..61e8df489e5 100644 --- a/cookbook/symfony1.rst +++ b/cookbook/symfony1.rst @@ -218,11 +218,6 @@ Of course, there's nothing wrong with having multiple applications in your project, that's entirely up to you. A second application would mean a new directory, e.g. ``my_app/``, with the same basic setup as the ``app/`` directory. -.. tip:: - - Read the definition of a :term:`Project`, an :term:`Application`, and a - :term:`Bundle` in the glossary. - Bundles and Plugins ------------------- diff --git a/glossary.rst b/glossary.rst deleted file mode 100644 index ab895bf2731..00000000000 --- a/glossary.rst +++ /dev/null @@ -1,136 +0,0 @@ -:orphan: - -Glossary -======== - -.. glossary:: - :sorted: - - Distribution - A *Distribution* is a package made of the Symfony Components, a - selection of bundles, a sensible directory structure, a default - configuration, and an optional configuration system. - - Dependency Injection - The Dependency Injection is a design pattern highly used in the Symfony Framework. - It encourages loosely coupled and more maintainable architecture of an application. - The main principle of this pattern is that it allows developers to *inject* objects - (also known as services) in other objects, generally passing them as parameters. - Different levels of coupling between these objects can be established - depending on the method used to inject objects together. - The Dependency Injection pattern is the more often associated - to another specific type of object: the :doc:`/book/service_container`. - - Project - A *Project* is a directory composed of an Application, a set of - bundles, vendor libraries, an autoloader, and web front controller - scripts. - - Application - An *Application* is a directory containing the *configuration* for a - given set of Bundles. - - Bundle - A *Bundle* is a directory containing a set of files (PHP files, - stylesheets, JavaScripts, images, ...) that *implement* a single - feature (a blog, a forum, etc). In Symfony, (*almost*) everything - lives inside a bundle. (see :ref:`page-creation-bundles`) - - Front Controller - A *Front Controller* is a short PHP script that lives in the web directory - of your project. Typically, *all* requests are handled by executing - the same front controller, whose job is to bootstrap the Symfony - application. - - Controller - A *controller* is a PHP function that houses all the logic necessary - to return a ``Response`` object that represents a particular page. - Typically, a route is mapped to a controller, which then uses information - from the request to process information, perform actions, and ultimately - construct and return a ``Response`` object. - - Service - A *Service* is a generic term for any PHP object that performs a - specific task. A service is usually used "globally", such as a database - connection object or an object that delivers email messages. In Symfony, - services are often configured and retrieved from the service container. - An application that has many decoupled services is said to follow - a `service-oriented architecture`_. - - Service Container - A *Service Container*, also known as a *Dependency Injection Container*, - is a special object that manages the instantiation of services inside - an application. Instead of creating services directly, the developer - *trains* the service container (via configuration) on how to create - the services. The service container takes care of lazily instantiating - and injecting dependent services. See :doc:`/book/service_container` - chapter. - - HTTP Specification - The *HTTP Specification* is a document that describes the Hypertext - Transfer Protocol - a set of rules laying out the classic client-server - request-response communication. The specification defines the format - used for a request and response as well as the possible HTTP headers - that each may have. For more information, read the `HTTP Wikipedia`_ - article or the `HTTP 1.1 RFC`_. - - Environment - An environment is a string (e.g. ``prod`` or ``dev``) that corresponds - to a specific set of configuration. The same application can be run - on the same machine using different configuration by running the application - in different environments. This is useful as it allows a single application - to have a ``dev`` environment built for debugging and a ``prod`` environment - that's optimized for speed. - - Vendor - A *vendor* is a supplier of PHP libraries and bundles including Symfony - itself. Despite the usual commercial connotations of the word, vendors - in Symfony often (even usually) include free software. Any library you - add to your Symfony project should go in the ``vendor`` directory. See - :ref:`The Architecture: Using Vendors `. - - Acme - *Acme* is a sample company name used in Symfony demos and documentation. - It's used as a namespace where you would normally use your own company's - name (e.g. ``Acme\BlogBundle``). - - Action - An *action* is a PHP function or method that executes, for example, - when a given route is matched. The term action is synonymous with - *controller*, though a controller may also refer to an entire PHP - class that includes several actions. See the :doc:`Controller Chapter `. - - Asset - An *asset* is any non-executable, static component of a web application, - including CSS, JavaScript, images and video. Assets may be placed - directly in the project's ``web`` directory, or published from a :term:`Bundle` - to the web directory using the ``assets:install`` console task. - - Kernel - The *Kernel* is the core of Symfony. The Kernel object handles HTTP - requests using all the bundles and libraries registered to it. See - :ref:`The Architecture: The Application Directory ` and the - :doc:`Internal Events Reference `. - - Firewall - In Symfony, a *Firewall* doesn't have to do with networking. Instead, - it defines the authentication mechanisms (i.e. it handles the process - of determining the identity of your users), either for the whole - application or for just a part of it. See the - :doc:`/book/security` chapters. - - YAML - *YAML* is a recursive acronym for "YAML Ain't a Markup Language". It's a - lightweight, human friendly data serialization language used extensively in - Symfony's configuration files. See the :doc:`/components/yaml/introduction` - chapter. - - Annotation - Annotations are metadata written alongside your code. They can either be explanatory and will be - ignored during execution or add functionality to the line of code directly below as a means of - configuration. For example, the annotation ``@var`` describes the type of a variable, whereas in - Symfony2 ``@Assert`` can add validation to a member variable of a class (see :doc:`/book/validation` chapter). - -.. _`service-oriented architecture`: https://wikipedia.org/wiki/Service-oriented_architecture -.. _`HTTP Wikipedia`: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol -.. _`HTTP 1.1 RFC`: http://www.w3.org/Protocols/rfc2616/rfc2616.html diff --git a/quick_tour/the_architecture.rst b/quick_tour/the_architecture.rst index 20e64e1301e..a7d4e244685 100644 --- a/quick_tour/the_architecture.rst +++ b/quick_tour/the_architecture.rst @@ -10,8 +10,8 @@ into the architecture now. Understanding the Directory Structure ------------------------------------- -The directory structure of a Symfony :term:`application` is rather flexible, -but the recommended structure is as follows: +The directory structure of a Symfony application is rather flexible, but the +recommended structure is as follows: ``app/`` The application configuration, templates and translations. @@ -26,8 +26,9 @@ The ``web/`` Directory ~~~~~~~~~~~~~~~~~~~~~~ The web root directory is the home of all public and static files like images, -stylesheets and JavaScript files. It is also where each :term:`front controller` -lives, such as the production controller shown here:: +stylesheets and JavaScript files. It is also where each front controller (the +file that handles all requests to your application) lives, such as the +production controller shown here:: // web/app.php require_once __DIR__.'/../app/bootstrap.php.cache'; @@ -72,7 +73,7 @@ Understanding the Bundle System ------------------------------- This section introduces one of the greatest and most powerful features of -Symfony, the :term:`bundle` system. +Symfony: The bundle system. A bundle is kind of like a plugin in other software. So why is it called a *bundle* and not a *plugin*? This is because *everything* is a @@ -179,8 +180,8 @@ defines the configuration for a specific bundle. For example, ``framework`` configures the FrameworkBundle while ``swiftmailer`` configures the SwiftmailerBundle. -Each :term:`environment` can override the default configuration by providing -a specific configuration file. For example, the ``dev`` environment loads +Each environment can override the default configuration by providing a +specific configuration file. For example, the ``dev`` environment loads the ``config_dev.yml`` file, which loads the main configuration (i.e. ``config.yml``) and then modifies it to add some debugging tools: diff --git a/quick_tour/the_big_picture.rst b/quick_tour/the_big_picture.rst index 3e6d4cd915f..8786945fe50 100644 --- a/quick_tour/the_big_picture.rst +++ b/quick_tour/the_big_picture.rst @@ -199,10 +199,10 @@ environments**. What is an Environment? ~~~~~~~~~~~~~~~~~~~~~~~ -An :term:`environment` represents a group of configurations that's used -to run your application. Symfony defines two environments by default: ``dev`` -(suited for when developing the application locally) and ``prod`` (optimized -for when executing the application on production). +An environment represents a group of configurations that's used to run your +application. Symfony defines two environments by default: ``dev`` (suited for +when developing the application locally) and ``prod`` (optimized for when +executing the application on production). When you visit the ``http://localhost:8000`` URL in your browser, you're executing your Symfony application in the ``dev`` environment. To visit diff --git a/reference/constraints/Callback.rst b/reference/constraints/Callback.rst index 7a11cc206de..13897ba1673 100644 --- a/reference/constraints/Callback.rst +++ b/reference/constraints/Callback.rst @@ -244,7 +244,7 @@ You can then use the following configuration to invoke this validator: .. note:: The Callback constraint does *not* support global callback functions - nor is it possible to specify a global function or a :term:`service` method + nor is it possible to specify a global function or a service method as callback. To validate using a service, you should :doc:`create a custom validation constraint ` and add that new constraint to your class.