forked from orbit-oss/flask
Merge pull request #387 from FND/docs
documentation: minor stylistic adjustments
This commit is contained in:
commit
fbbe14791f
3 changed files with 7 additions and 7 deletions
|
|
@ -58,7 +58,7 @@ Dispatch by Subdomain
|
||||||
|
|
||||||
Sometimes you might want to use multiple instances of the same application
|
Sometimes you might want to use multiple instances of the same application
|
||||||
with different configurations. Assuming the application is created inside
|
with different configurations. Assuming the application is created inside
|
||||||
a function and you can call that function to instanciate it, that is
|
a function and you can call that function to instantiate it, that is
|
||||||
really easy to implement. In order to develop your application to support
|
really easy to implement. In order to develop your application to support
|
||||||
creating new instances in functions have a look at the
|
creating new instances in functions have a look at the
|
||||||
:ref:`app-factories` pattern.
|
:ref:`app-factories` pattern.
|
||||||
|
|
|
||||||
|
|
@ -74,7 +74,7 @@ enough to explain the basic principle. When you have a class based view
|
||||||
the question comes up what `self` points to. The way this works is that
|
the question comes up what `self` points to. The way this works is that
|
||||||
whenever the request is dispatched a new instance of the class is created
|
whenever the request is dispatched a new instance of the class is created
|
||||||
and the :meth:`~flask.views.View.dispatch_request` method is called with
|
and the :meth:`~flask.views.View.dispatch_request` method is called with
|
||||||
the parameters from the URL rule. The class itself is instanciated with
|
the parameters from the URL rule. The class itself is instantiated with
|
||||||
the parameters passed to the :meth:`~flask.views.View.as_view` function.
|
the parameters passed to the :meth:`~flask.views.View.as_view` function.
|
||||||
For instance you can write a class like this::
|
For instance you can write a class like this::
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -70,10 +70,10 @@ class View(object):
|
||||||
|
|
||||||
@classmethod
|
@classmethod
|
||||||
def as_view(cls, name, *class_args, **class_kwargs):
|
def as_view(cls, name, *class_args, **class_kwargs):
|
||||||
"""Converts the class into an actual view function that can be
|
"""Converts the class into an actual view function that can be used
|
||||||
used with the routing system. What it does internally is generating
|
with the routing system. Internally this generates a function on the
|
||||||
a function on the fly that will instanciate the :class:`View`
|
fly which will instantiate the :class:`View` on each request and call
|
||||||
on each request and call the :meth:`dispatch_request` method on it.
|
the :meth:`dispatch_request` method on it.
|
||||||
|
|
||||||
The arguments passed to :meth:`as_view` are forwarded to the
|
The arguments passed to :meth:`as_view` are forwarded to the
|
||||||
constructor of the class.
|
constructor of the class.
|
||||||
|
|
@ -90,7 +90,7 @@ class View(object):
|
||||||
|
|
||||||
# we attach the view class to the view function for two reasons:
|
# we attach the view class to the view function for two reasons:
|
||||||
# first of all it allows us to easily figure out what class based
|
# first of all it allows us to easily figure out what class based
|
||||||
# view this thing came from, secondly it's also used for instanciating
|
# view this thing came from, secondly it's also used for instantiating
|
||||||
# the view class so you can actually replace it with something else
|
# the view class so you can actually replace it with something else
|
||||||
# for testing purposes and debugging.
|
# for testing purposes and debugging.
|
||||||
view.view_class = cls
|
view.view_class = cls
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue