forked from orbit-oss/flask
Fix some typos in the docs
Signed-off-by: Armin Ronacher <armin.ronacher@active-4.com>
This commit is contained in:
parent
41f5ad9b15
commit
540eca16f8
4 changed files with 9 additions and 9 deletions
|
|
@ -160,7 +160,7 @@ initialization functions:
|
|||
classes:
|
||||
Classes work mostly like initialization functions but can later be
|
||||
used to further change the behaviour. For an example look at how the
|
||||
`OAuth extension`_ works: ther is an `OAuth` object that provides
|
||||
`OAuth extension`_ works: there is an `OAuth` object that provides
|
||||
some helper functions like `OAuth.remote_app` to create a reference to
|
||||
a remote application that uses OAuth.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Application Factories
|
|||
=====================
|
||||
|
||||
If you are already using packages and modules for your application
|
||||
(:ref:`packages`) there are couple of really nice ways to further improve
|
||||
(:ref:`packages`) there are a couple of really nice ways to further improve
|
||||
the experience. A common pattern is creating the application object when
|
||||
the module is imported. But if you move the creation of this object,
|
||||
into a function, you can then create multiple instances of this and later.
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@
|
|||
Patterns for Flask
|
||||
==================
|
||||
|
||||
Certain things are common enough that the changes are high you will find
|
||||
Certain things are common enough that the chances are high you will find
|
||||
them in most web applications. For example quite a lot of applications
|
||||
are using relational databases and user authentication. In that case,
|
||||
changes are they will open a database connection at the beginning of the
|
||||
chances are they will open a database connection at the beginning of the
|
||||
request and get the information of the currently logged in user. At the
|
||||
end of the request, the database connection is closed again.
|
||||
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ following quick checklist:
|
|||
Not the object itself, but the module it is in. Do the importing at
|
||||
the *bottom* of the file.
|
||||
|
||||
Here an example `__init__.py`::
|
||||
Here's an example `__init__.py`::
|
||||
|
||||
from flask import Flask
|
||||
app = Flask(__name__)
|
||||
|
|
@ -109,7 +109,7 @@ Working with Modules
|
|||
--------------------
|
||||
|
||||
For larger applications with more than a dozen views it makes sense to
|
||||
split the views into modules. First let's look at the typical struture of
|
||||
split the views into modules. First let's look at the typical structure of
|
||||
such an application::
|
||||
|
||||
/yourapplication
|
||||
|
|
@ -133,10 +133,10 @@ sure to place an empty `__init__.py` file in there. Let's start with the
|
|||
|
||||
First we have to create a :class:`~flask.Module` object with the name of
|
||||
the package. This works very similar to the :class:`~flask.Flask` object
|
||||
you have already worked with, it just does not support all of the method,
|
||||
you have already worked with, it just does not support all of the methods,
|
||||
but most of them are the same.
|
||||
|
||||
Long story short, here a nice and concise example::
|
||||
Long story short, here's a nice and concise example::
|
||||
|
||||
from flask import Module
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ Long story short, here a nice and concise example::
|
|||
pass
|
||||
|
||||
@admin.route('/logout')
|
||||
def login():
|
||||
def logout():
|
||||
pass
|
||||
|
||||
Do the same with the `frontend.py` and then make sure to register the
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue