1. Hynek Cernoch
  2. django-livesettings

Commits

Hynek Cernoch  committed 5c68c9a Draft

Fixed html docs.

  • Participants
  • Parent commits 2bbbaaa
  • Branches default

Comments (0)

Files changed (3)

File docs/conf.py

View file
  • Ignore whitespace
 # built documents.
 #
 # The short X.Y version.
-version = '1.4.9'
+version = '1.4.13'
 # The full version, including alpha/beta/rc tags.
-release = '1.4.9'
+release = '1.4.13'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
+#html_static_path = ['_static']
 
 # If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
 # using the given strftime format.

File docs/installation.rst

View file
  • Ignore whitespace
 It is high recommended to configure a global cache (like `MemcachedCache`) for
 multiprocess servers! Otherwise the processes would not be notified about new
 values with the default `LocMemCache`. The default configuration is safe for
-a debug server (manage.py runserver).
+a debug server (``manage.py runserver``).
 
 
 Add it to your :file:`urls.py`::
         ...
     )
     
-Execute a syncdb to create the required tables::
+Execute a ``syncdb`` to create the required tables::
 
     python manage.py syncdb
     

File docs/usage.rst

View file
  • Ignore whitespace
 ------------------
 
 In order to use livesettings, you will need to create a :file:`config.py` in your django application.
-For this example, we will create a :file:`config.py` file in the 'test-project/localsite' directory.
+For this example, we will create a :file:`config.py` file in the :file:`test-project/localsite` directory.
 
-Example: "For this specific app, we want to allow an admin user to control how many images are displayed on the front page of our site."
+Example: For our specific app, we want to allow an admin user to control how many images are displayed on the front page of our site.
 We will create the following :file:`config.py`::
 
     from livesettings import config_register, ConfigurationGroup, PositiveIntegerValue, MultipleStringValue
 
     import config
     
-You can now see the results of your work by running the dev server and going to `settings <http://127.0.0.1:8000/settings/>`_ ::
+You can now see the results of your work by running the dev server and going to http://127.0.0.1:8000/settings/:
+
+.. code-block:: bash
 
     python manage.py runserver
 
-Dislayed values can be limited to a configuration group by the url. For example
-we want to do experiments with configuration group `MyApp` only:
-`group settings <http://127.0.0.1:8000/settings/MyApp>`_ ::
-where `MyApp` is the key name of the displayed group.
+Displayed values can be limited to a configuration group by the url. For example
+if we want to do experiments with configuration group `MyApp` settings only, we
+go to http://127.0.0.1:8000/settings/MyApp/.
 
 More examples for all implemented types of ..Values can be found in
 :file:`test-project/localsite/config.py`::
 including configuration groups which are enabled or disabled based on modules selected in the form.
 You can review examples by:
 
+.. code-block:: bash
+
     cd test-project
     python manage.py runserver
     
-and browse `<http://127.0.0.1:8000/settings/>`.
+and browse http://127.0.0.1:8000/settings/.
 
 Accessing your value in a view
 ------------------------------
 
 Now that you have been able to set a value and allow a user to change it, the next step is to access it from a view. 
 
-In a :file:`views.py`, you can use the config_value function to get access to the value. Here is a very simple view that passes the value to your template::
+In a :file:`views.py`, you can use the ``config_value`` function to get access to the value. Here is a very simple view that passes the value to your template::
 
 
     from django.shortcuts import render_to_response
 Security and Restricting Access to Livesettings
 -----------------------------------------------
 
-In order to give non-superusers access to the /settings/ views, open Django Admin Auth screen
-and give the user or to its group the permission *livesettings|setting|Can change settting*.
+In order to give non-superusers access to the ``/settings/`` views, open Django Admin Auth screen
+and give the user or to its group the permission ``livesettings|setting|Can change settting``.
 The same permission is needed to view the form and submit.
-Permissions for insert or delete and any permissions for "long setting" are ignored.
+Permissions for insert or delete and any permissions for ``long setting`` are ignored.
 
 .. Note::
     Superusers will have access to this setting without enabling any specific permissions.
     Because of the security significance of livesettings, all views in livesettings support CSRF regardless of whether or not the 
     CsrfViewMiddleware is enabled or disabled.
 
-If you want to save a sensitive information to livesettings on production site (e.g. a password for logging into other web service)
-it is recommended not to grant permissions to livesettings to users which are logging in everyday.
+If you want to save a sensitive information to livesettings on a production site (e.g. a password for logging into other web service)
+it is recommended not to grant permissions to livesettings to users who log on everyday.
 The most secure method is to export the settings and disable web access to livesettings as described below.
 Exporting settings itself is allowed only by the superuser.
 
-Password values should be declared by `PasswordValue(... render_value=False)`
+Password values should be declared by ``PasswordValue(... render_value=False)``
 that replaces password characters by asterisks in the browser. (Though hidden
 to a human observer, password is still accessible by attacker's javascripts or
 by connection eavesdropping.)
 Exporting Settings
 ------------------
 
-Settings can be exported by the `http://127.0.0.1:8000/settings/export/ <http://127.0.0.1:8000/settings/export/>`_ . After exporting the file, the entire
+Settings can be exported by the http://127.0.0.1:8000/settings/export/. After exporting the file, the entire
 output can be manually copied and pasted to :file:`settings.py` in order to deploy configuration to more sites
 or to entirely prevent further changes and reading by web browser.
 If you restrict DB access to the settings, all of the livesettings_* tables will be unused. 
 Notes
 -----
 
-If you use logging with the level DEBUG in your application, prevent increasing of logging level of keyedcache by configuring it in settings.py::
+If you use logging with the level ``DEBUG`` in your application, prevent increasing
+of logging level of ``keyedcache`` by configuring it in ``settings.py``::
 
     import logging
     logging.getLogger('keyedcache').setLevel(logging.INFO)
 Next Steps
 ----------
 
-The rest of the various livesettings types can be used in a similar manner. You can review the `satchmo code <https://bitbucket.org/chris1610/satchmo/src>`_ for more advanced examples.
+The rest of the various livesettings types can be used in a similar manner. You
+can review the `satchmo code <https://bitbucket.org/chris1610/satchmo/src>`_
+for more advanced examples.
 
 
 .. _`Django-Keyedcache`: http://bitbucket.org/bkroeze/django-keyedcache/