Updated design decisions. This fixes #63

CHANGES

@@ -19,6 +19,7 @@ Release date to be announced, codename to be selected.
 - because the Python standard library caches loggers, the name of
   the logger is configurable now to better support unittests.
 - added `TESTING` switch that can activate unittesting helpers.
+- the logger switches to `DEBUG` mode now if debug is enabled.
 
 Version 0.3.1
 -------------

docs/design.rst

@@ -73,6 +73,10 @@ want to apply a WSGI middleware, just wrap it and you're done (though
 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
+things (:ref:`app-factories`).
+
 One Template Engine
 -------------------
 
@@ -145,3 +149,21 @@ quick and easy to write a traditional web application.
 
 Also see the :ref:`becomingbig` section of the documentation for some
 inspiration for larger applications based on Flask.
+
+
+What Flask is, What Flask is Not
+--------------------------------
+
+Flask will never have a database layer.  It will not have a form library
+or anything else in that direction.  Flask itself just bridges to Werkzeug
+to implement a proper WSGI application and to Jinja2 to handle templating.
+It also binds to a few common standard library packages such as logging.
+Everything else is up for extensions.
+
+Why is this the case?  Because people have different preferences and
+requirements and Flask could not meet those if it would force any of this
+into the core.  The majority of web applications will need a template
+engine in some sort.  However not every application needs a SQL database.
+
+The idea of Flask is to build a good foundation for all applications.
+Everything else is up to you or extensions.