forked from orbit-oss/flask
Fix various small spelling errors.
This commit is contained in:
parent
7f782ba84e
commit
4e272fc042
9 changed files with 14 additions and 14 deletions
|
|
@ -49,7 +49,7 @@ Typically, an application context will have the same lifetime as a
|
|||
request.
|
||||
|
||||
See :doc:`/reqcontext` for more information about how the contexts work
|
||||
and the full lifecycle of a request.
|
||||
and the full life cycle of a request.
|
||||
|
||||
|
||||
Manually Push a Context
|
||||
|
|
|
|||
|
|
@ -96,6 +96,6 @@ Discuss with the community.
|
|||
|
||||
The Flask developers keep the framework accessible to users with codebases big
|
||||
and small. If you find an obstacle in your way, caused by Flask, don't hesitate
|
||||
to contact the developers on the mailinglist or IRC channel. The best way for
|
||||
to contact the developers on the mailing list or IRC channel. The best way for
|
||||
the Flask and Flask extension developers to improve the tools for larger
|
||||
applications is getting feedback from users.
|
||||
|
|
|
|||
|
|
@ -244,7 +244,7 @@ was dispatched to any other admin blueprint endpoint.
|
|||
Error Handlers
|
||||
--------------
|
||||
|
||||
Blueprints support the errorhandler decorator just like the :class:`Flask`
|
||||
Blueprints support the ``errorhandler`` decorator just like the :class:`Flask`
|
||||
application object, so it is easy to make Blueprint-specific custom error
|
||||
pages.
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ concerning handlers for 404 and 405 exceptions. These errorhandlers are only
|
|||
invoked from an appropriate ``raise`` statement or a call to ``abort`` in another
|
||||
of the blueprint's view functions; they are not invoked by, e.g., an invalid URL
|
||||
access. This is because the blueprint does not "own" a certain URL space, so
|
||||
the application instance has no way of knowing which blueprint errorhandler it
|
||||
the application instance has no way of knowing which blueprint error handler it
|
||||
should run if given an invalid URL. If you would like to execute different
|
||||
handling strategies for these errors based on URL prefixes, they may be defined
|
||||
at the application level using the ``request`` proxy object::
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ toggling the debug mode, setting the secret key, and other such
|
|||
environment-specific things.
|
||||
|
||||
The way Flask is designed usually requires the configuration to be
|
||||
available when the application starts up. You can hardcode the
|
||||
available when the application starts up. You can hard code the
|
||||
configuration in the code, which for many small applications is not
|
||||
actually that bad, but there are better ways.
|
||||
|
||||
|
|
@ -494,7 +494,7 @@ that experience:
|
|||
|
||||
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
|
||||
different configurations attached which makes unit testing a lot
|
||||
easier. You can use this to pass in configuration as needed.
|
||||
|
||||
2. Do not write code that needs the configuration at import time. If you
|
||||
|
|
@ -527,7 +527,7 @@ the config file by adding ``from yourapplication.default_settings
|
|||
import *`` to the top of the file and then overriding the changes by hand.
|
||||
You could also inspect an environment variable like
|
||||
``YOURAPPLICATION_MODE`` and set that to `production`, `development` etc
|
||||
and import different hardcoded files based on that.
|
||||
and import different hard-coded files based on that.
|
||||
|
||||
An interesting pattern is also to use classes and inheritance for
|
||||
configuration::
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ the time. There are ways to fake multiple applications with a single
|
|||
application object, like maintaining a stack of applications, but this
|
||||
causes some problems I won't outline here in detail. Now the question is:
|
||||
when does a microframework need more than one application at the same
|
||||
time? A good example for this is unittesting. When you want to test
|
||||
time? A good example for this is unit testing. When you want to test
|
||||
something it can be very helpful to create a minimal application to test
|
||||
specific behavior. When the application object is deleted everything it
|
||||
allocated will be freed again.
|
||||
|
|
@ -76,7 +76,7 @@ there are better ways to do that so that you do not lose the reference
|
|||
to the application object :meth:`~flask.Flask.wsgi_app`).
|
||||
|
||||
Furthermore this design makes it possible to use a factory function to
|
||||
create the application which is very helpful for unittesting and similar
|
||||
create the application which is very helpful for unit testing and similar
|
||||
things (:ref:`app-factories`).
|
||||
|
||||
The Routing System
|
||||
|
|
|
|||
|
|
@ -287,7 +287,7 @@ also avoids having multiple developers working in isolation on pretty much the
|
|||
same problem.
|
||||
|
||||
Remember: good API design is hard, so introduce your project on the
|
||||
mailinglist, and let other developers give you a helping hand with
|
||||
mailing list, and let other developers give you a helping hand with
|
||||
designing the API.
|
||||
|
||||
The best Flask extensions are extensions that share common idioms for the
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Extensions
|
|||
Extensions are extra packages that add functionality to a Flask
|
||||
application. For example, an extension might add support for sending
|
||||
email or connecting to a database. Some extensions add entire new
|
||||
frameworks to help build certain types of applications, like a ReST API.
|
||||
frameworks to help build certain types of applications, like a REST API.
|
||||
|
||||
|
||||
Finding Extensions
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ can you do?
|
|||
|
||||
This is where some helper functions come in handy. Keep in mind however
|
||||
that these functions are not only there for interactive shell usage, but
|
||||
also for unittesting and other situations that require a faked request
|
||||
also for unit testing and other situations that require a faked request
|
||||
context.
|
||||
|
||||
Generally it's recommended that you read the :ref:`request-context`
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@ The Golden Rule
|
|||
So the rule of thumb: if you are not dealing with binary data, work with
|
||||
Unicode. What does working with Unicode in Python 2.x mean?
|
||||
|
||||
- as long as you are using ASCII charpoints only (basically numbers,
|
||||
some special characters of latin letters without umlauts or anything
|
||||
- as long as you are using ASCII code points only (basically numbers,
|
||||
some special characters of Latin letters without umlauts or anything
|
||||
fancy) you can use regular string literals (``'Hello World'``).
|
||||
- if you need anything else than ASCII in a string you have to mark
|
||||
this string as Unicode string by prefixing it with a lowercase `u`.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue