Fix a few typos/spelling in the docs

Author: Cito

docs/changes.rst

@@ -10,18 +10,18 @@ This is the full list of changes in Webware for Python 3 (first version 3.0.0) c
 
 * Webware for Python 3 now requires Python 3.6 or newer, and makes internal use of newer Python features where applicable. Webware applications must now be migrated to or written for Python 3.
 * The "Application" instance is now callable and usable as a WSGI application.
-* The application server ("AppServer" class and subclasses including the "ThreadedAppServer") and the the various adapters and start scripts and other related scripts for the application server are not supported any more. Instead, Webware applications are now supposed to be served as WSGI applications using a WSGI server such as waitress, which is now used as the development server.
+* The application server ("AppServer" class and subclasses including the "ThreadedAppServer") and the various adapters and start scripts and other related scripts for the application server are not supported anymore. Instead, Webware applications are now supposed to be served as WSGI applications using a WSGI server such as waitress, which is now used as the development server.
 * The "ASSStreamOut" class has been replaced by a "WSGIStreamOut" class. The "Message" class has been removed, since it was not really used for anything, simplifying the class hierarchy a bit.
 * The Application now has a development flag that can be checked to modify the application and its configuration depending on whether it is running in development or production mode.
-* The custom "install" script has been replaced by a standard "setup" script, Webware for Python 3 is now distributed as a normal Python package that can be installed in the usual way. The "ReleaseHelper" and "setversion" scripts are not used any more.
+* The custom "install" script has been replaced by a standard "setup" script, Webware for Python 3 is now distributed as a normal Python package that can be installed in the usual way. The "ReleaseHelper" and "setversion" scripts are not used anymore.
 * The "MakeAppWorkDir" script has been moved to a new "Scripts" directory, which now also contains a "WSGIScript" and a "WaitressServer" script which serve as replacements for the old "AppServer" and "Launch" start scripts. These scripts can now be started as subcommands of a new webware console script, which serves as a new common Webware CLI.
 * Instead of the "AutoReloadingAppServer", you can use the "reload" option of the WaitressServer script which uses hupper to monitor the application files and reload the waitress server if necessary. The "ImportSpy" has been removed.
 * The classes of the core "WebKit" component are now available at the root level of Webware for Python 3, and the WebKit component ceased to exist as a separate plug-in.
-* Some built-in plug-ins are not supported any more: "CGIWrapper", "ComKit" and "KidKit".
-* "MiddleKit" is not a built-in plug-in any more, but is provided as a separate project on GitHub now (WebwareForPython/w4py3-middlekit).
+* Some built-in plug-ins are not supported anymore: "CGIWrapper", "ComKit" and "KidKit".
+* "MiddleKit" is not a built-in plug-in anymore, but is provided as a separate project on GitHub now (WebwareForPython/w4py3-middlekit).
 * Webware now uses entry points for discovering plug-ins instead of the old plug-in system, and the plug-in API has slightly changed. Existing plug-ins must be adapted to Python 3 and the new plug-in API.
 * The documentation has been moved to a separate directory and is built using Sphinx, instead providing a "Docs" context for Webware and every plug-in, and using custom documentation builders in the install script. The existing content has been reformatted for Sphinx, adapted and supplemented.
-* The various examples have been slightly improved and updated. Demo servlets showing the use of Dominate abd Yattag for creating HTML in a Pythonic way have been added.
+* The various examples have been slightly improved and updated. Demo servlets showing the use of Dominate and Yattag for creating HTML in a Pythonic way have been added.
 * The side bar page layout now uses divs instead of tables.
 * The test suite has been expanded and fully automated using the unit testing framework in the Python standard library. We also use tox to automate various checks and running the test suite with different Python versions.
 * In particular, end-to-end tests using Twill have been replaced by more efficient unit tests using WebTest.

docs/deploy.rst

@@ -613,7 +613,7 @@ By activating the virtual environment, you make sure that you compile the source
 
 If you want to serve contexts outside the application working directory, like the default Examples or Admin context, you need to compile these as well, in a similar way.
 
-You can now remove all the source files except the WSGI script and the ``__pycache__`` directories, they are not needed on the production system any more::
+You can now remove all the source files except the WSGI script and the ``__pycache__`` directories, they are not needed on the production system anymore::
 
     cd path-to-app-work-dir
     find . -type f -name '*.py' -delete -o \
@@ -645,7 +645,7 @@ This is totally doable, and may make sense in order to better utilize existing h
 - The Webware TaskManager will be started with every Application process. If this is not what you want, you can change the ``RunTasks`` configuration setting to False, and run the TaskManager in a dedicated process.
 - Some load balancers support "sticky sessions", identifying clients by their session cookies and dispatching them to the same server processes. But usually, in multiprocessing mode, you cannot guarantee that requests from the same client are served by the same process, and it would also partially defeat the whole purpose of running multiple processes. Therefore, the SessionMemoryStore, SessionFileStore and SessionDynamicStore are not suitable in that mode, since the session data that is created in the local memory of one process will not be available in a different process. Also, accessing session files from different processes simultaneously can be problematic. Instead, we recommend changing the ``SessionStore`` configuration setting to use the SessionRedisStore or the SessionMemcachedStore. Storing the session data in the database is also possible, but may degrade performance.
 - When caching frequently used data in local memory, this will become less effective and waste memory when running multiple processes. Consider using a distributed caching system such as Redis_ or Memcached_ instead. If you are using the SessionRedisStore or the SessionMemcachedStore, you will need to install one of these systems anyway.
-- Webware applications often store global, application wide state in class attributes of servlet classes or elsewhere in local memory. Again, be aware that this does not work any more if you are running the same application in multiple processes.
+- Webware applications often store global, application wide state in class attributes of servlet classes or elsewhere in local memory. Again, be aware that this does not work anymore if you are running the same application in multiple processes.
 - Redirecting standard error and output to the same log file is not supported when running multiple processes, so the ``LogFilename`` setting should be set to None, and a different logging mechanism should be used. When using mod_wsgi you may need to use the ``WSGIRestrictStdout`` directive and log on that level. Future versions of Webware for Python 3 will address this problem and provide proper logging mechanisms instead of just printing to stdout.
 
 .. _Redis: https://redis.io/

docs/migrate.rst

@@ -5,7 +5,7 @@ Migration Guide
 
 In this chapter we try to give some advice on what needs to be done to migrate an existing Webware for Python application to Webware for Python 3.
 
-Regarding the API, we tried to stay compatible with Webware for Python 2 as much as possible, even though modern Python uses different naming conventions  and prefers the use of properties over getter and setter methods. So, in this regard, we expect a migration to Webware for Python 3 to be very smooth. The main points in a migration will be the conversion of the application from Python 2 to Python 3. the adaptation to the use of the WSGI standard instead of the custom application server, and maybe the usage of Webware plug-ins that are not supported any more and may need to be migrated as well.
+Regarding the API, we tried to stay compatible with Webware for Python 2 as much as possible, even though modern Python uses different naming conventions  and prefers the use of properties over getter and setter methods. So, in this regard, we expect a migration to Webware for Python 3 to be very smooth. The main points in a migration will be the conversion of the application from Python 2 to Python 3. the adaptation to the use of the WSGI standard instead of the custom application server, and maybe the usage of Webware plug-ins that are not supported anymore and may need to be migrated as well.
 
 Check which Webware plug-ins you were using
 -------------------------------------------
@@ -17,7 +17,7 @@ First you should check whether the plug-ins your application is using are still
 Migrate your application to Python 3
 ------------------------------------
 
-The main migration effort will be porting your Webware application from Python 2 to Python 3. More precisely, Webware for Python 3 requires Python 3.6 or newer. This effort is necessary anyway, if you want to keep your Webware application alive for some more years, because the Python foundation declared to end Python 2 support on January 1st 2020, which means that Python 2 will also not be supported by newer operating systems any more and not even get security updates any more. The positive aspect of this is that your Webware application will run slightly faster and you can now make use of all the modern Python features and libraries in your application. Particularly, f-strings can be very handy when creating Webware applications.
+The main migration effort will be porting your Webware application from Python 2 to Python 3. More precisely, Webware for Python 3 requires Python 3.6 or newer. This effort is necessary anyway, if you want to keep your Webware application alive for some more years, because the Python foundation declared to end Python 2 support on January 1st 2020, which means that Python 2 will also not be supported by newer operating systems anymore and not even get security updates anymore. The positive aspect of this is that your Webware application will run slightly faster and you can now make use of all the modern Python features and libraries in your application. Particularly, f-strings can be very handy when creating Webware applications.
 
 We will not go into the details of migrating your application from Python 2 to Python 3 here, since much good advice is already available on the Internet, for instance:
 
@@ -39,6 +39,6 @@ Use a WSGI server instead of the WebKit application server
 
 The other big change is that instead of using the custom "WebKit" application server, Webware for Python 3 utilizes the WSGI standard as the only way of serving applications. You will need to adapt your deployment accordingly. See the section on :ref:`deployment` for instructions on how to get your application into production using WSGI.
 
-Search your application for direct references to the ``AppServer`` instance which does not exist any more in Webware for Python 3. In most cases, you can replace these with references to the ``Application`` instance which also serves as the WSGI callable.
+Search your application for direct references to the ``AppServer`` instance which does not exist anymore in Webware for Python 3. In most cases, you can replace these with references to the ``Application`` instance which also serves as the WSGI callable.
 
-Also, search for references to the former ``WebKit`` package. This package does not exist any more as separate plug-in in Webware for Python 3, its classes can now be found directly in the top level package of Webware for Python 3. So an import statement like ``from WebKit.Page import Page`` should be changed to a simple ``from Page import Page``.
+Also, search for references to the former ``WebKit`` package. This package does not exist anymore as separate plug-in in Webware for Python 3, its classes can now be found directly in the top level package of Webware for Python 3. So an import statement like ``from WebKit.Page import Page`` should be changed to a simple ``from Page import Page``.