orbit-oss/flask
4
4
Fork 2
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Proofreading the documentation

Browse source
This commit is contained in:
Chris Edgemon 2010-04-19 23:25:51 -05:00
parent 4ff9493e57
commit a7ff9dbddd
8 changed files with 58 additions and 58 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/becomingbig.rst
View file

@ -8,11 +8,11 @@ designed for large scale applications and does not attempt to do so, but
that does not mean you picked the wrong tool in the first place.
Flask is powered by Werkzeug and Jinja2, two libraries that are in use at
a number of large websites out there and all Flask does is bringing those
a number of large websites out there and all Flask does is bring those
two together. Being a microframework, Flask is literally a single file.
What that means for large applications is that it's probably a good idea
to take the code from Flask and put it into a new module within the
applications and expanding on that.
applications and expand on that.
What Could Be Improved?
-----------------------
@ -20,12 +20,12 @@ What Could Be Improved?
For instance it makes a lot of sense to change the way endpoints (the
names of the functions / URL rules) are handled to also take the module
name into account. Right now the function name is the URL name, but
imagine you have a large applications consisting of multiple components.
imagine you have a large application consisting of multiple components.
In that case, it makes a lot of sense to use dotted names for the URL
endpoints.
Here some suggestions how Flask can be modified to better accomodate large
scale applications:
Here are some suggestions for how Flask can be modified to better
accomodate large-scale applications:
- implement dotted names for URL endpoints
- get rid of the decorator function registering which causes a lot
@ -35,7 +35,7 @@ scale applications:
better solution would be to have one module with all URLs in there and
specifing the target functions explicitly or by name and importing
them when needed.
- switch to explicit request object passing. This makes it more to type
- switch to explicit request object passing. This requires more typing
(because you now have something to pass around) but it makes it a
whole lot easier to debug hairy situations and to test the code.
- integrate the `Babel`_ i18n package or `SQLAlchemy`_ directly into the
@ -44,14 +44,14 @@ scale applications:
.. _Babel: http://babel.edgewall.org/
.. _SQLAlchemy: http://www.sqlalchemy.org/
Why does not Flask do all that by Default?
Why does Flask not do all that by Default?
------------------------------------------
There is a huge difference between a small application that only has to
handle a couple of requests per second and with an overall code complexity
of less than 4000 lines of code or something of larger scale. At one
of less than 4000 lines of code and something of larger scale. At some
point it becomes important to integrate external systems, different
storage backends and more.
If Flask was designed with all these contingencies in mind, it would be a
much more complex framework and less easy to get started with.
much more complex framework and harder to get started with.