diff --git a/docs/becomingbig.rst b/docs/becomingbig.rst index 62f456bd..8b0a2743 100644 --- a/docs/becomingbig.rst +++ b/docs/becomingbig.rst @@ -12,7 +12,7 @@ Flask started in part to demonstrate how to build your own framework on top of existing well-used tools Werkzeug (WSGI) and Jinja (templating), and as it developed, it became useful to a wide audience. As you grow your codebase, don't just use Flask -- understand it. Read the source. Flask's code is -written to be read; it's documentation published so you can use its internal +written to be read; it's documentation is published so you can use its internal APIs. Flask sticks to documented APIs in upstream libraries, and documents its internal utilities so that you can find the hook points needed for your project. diff --git a/docs/config.rst b/docs/config.rst index dfcead34..cd2afebb 100644 --- a/docs/config.rst +++ b/docs/config.rst @@ -194,7 +194,7 @@ The following configuration values are used internally by Flask: browsers will not allow cross-subdomain cookies to be set on a server name without dots in it. So if your server name is ``'localhost'`` you will not be able to set a cookie for - ``'localhost'`` and every subdomain of it. Please chose a different + ``'localhost'`` and every subdomain of it. Please choose a different server name in that case, like ``'myapplication.local'`` and add this name + the subdomains you want to use into your host config or setup a local `bind`_. @@ -287,7 +287,7 @@ a little harder. There is no single 100% solution for this problem in general, but there are a couple of things you can keep in mind to improve that experience: -1. create your application in a function and register blueprints on it. +1. Create your application in a function and register blueprints on it. That way you can create multiple instances of your application with different configurations attached which makes unittesting a lot easier. You can use this to pass in configuration as needed. @@ -348,10 +348,10 @@ To enable such a config you just have to call into There are many different ways and it's up to you how you want to manage your configuration files. However here a list of good recommendations: -- keep a default configuration in version control. Either populate the +- Keep a default configuration in version control. Either populate the config with this default configuration or import it in your own configuration files before overriding values. -- use an environment variable to switch between the configurations. +- Use an environment variable to switch between the configurations. This can be done from outside the Python interpreter and makes development and deployment much easier because you can quickly and easily switch between different configs without having to touch the diff --git a/docs/shell.rst b/docs/shell.rst index f4522c1a..f622be9d 100644 --- a/docs/shell.rst +++ b/docs/shell.rst @@ -98,6 +98,6 @@ with stuff you want to star import into your interactive session. There you could also define some more helper methods for common things such as initializing the database, dropping tables etc. -Just put them into a module (like `shelltools` and import from there): +Just put them into a module (like `shelltools`) and import from there: >>> from shelltools import * diff --git a/docs/templating.rst b/docs/templating.rst index bf672672..8b7caf44 100644 --- a/docs/templating.rst +++ b/docs/templating.rst @@ -119,7 +119,7 @@ Controlling Autoescaping ------------------------ Autoescaping is the concept of automatically escaping special characters -of you. Special characters in the sense of HTML (or XML, and thus XHTML) +for you. Special characters in the sense of HTML (or XML, and thus XHTML) are ``&``, ``>``, ``<``, ``"`` as well as ``'``. Because these characters carry specific meanings in documents on their own you have to replace them by so called "entities" if you want to use them for text. Not doing so