forked from orbit-oss/flask
commit
02f0c755a3
4 changed files with 7 additions and 7 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 *
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue