-
Notifications
You must be signed in to change notification settings - Fork 0
settings.py (page)
The settings.py file holds all of the settings for the project. This defines all the installed apps (including wiki and other third party apps), something called middleware classes, where to find different things (like templates and static files).
One of the first things you see in the file is:
SECRET_KEY = 'qe5+tv4aht^^8x^g5d-$@4%xy9be-q32*o)6@xc-%!#)7)^3^h'This is a random generated key used for encryption. As you might guess from the name, this is ment to be secret, and therefor you will need to generate a new secret key if you want to put the wiki in production.
A more elegant way to solve this, taken from this stackoverflow answer, is to use a separate file to store the secret key, and import the key from this file. The file containing the secret key will not be included, so the first time the system starts, it will detect that the file is missing, and generate it. It would look something like this:
from django.utils.crypto import get_random_string
try:
from secret_key import *
except ImportError:
SETTINGS_DIR=os.path.abspath(os.path.dirname(__file__))
chars = 'abcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*(-_=+)'
f = open(os.path.join(SETTINGS_DIR, 'secret_key.py'), 'w')
f.write('SECRET_KEY={secret}'.format(secret=get_random_string(50, chars)))
from secret_key import *The next interesting part is the installed apps:
INSTALLED_APPS = (
...
'wiki',
'django_markdown',
'whoosh',
'haystack',
'reversion',
'reversion_compare',
)There are six custom installed apps: wiki, django_markdown, whoosh, haystack, reversion and reversion_compare.
The Django Markdown app provides the markdown functionality used in the wiki. It is the app that convert the markdown syntax (written by users) to HTML syntax (interpreted by the browser).
Whoosh is the search backend used by haystack
Heystack provides indexing and searchability of the data in specified models (databases). In our case we use it to index the text, title and date field in the page-model (the model for all the pages). This gives ut a full text search of all the pages in the wiki. You can read the full documentation of haystack here.
This is the app that gives us the option to revert (roll back) changes made (theoretically infinitely log ago). Whenever a change is made to the registered models (we only registered the page model to use reversion), the reversion app stores the previous data (before the change). This makes it also possible for us to revive deleted page. Here's the github-page for the app: github.com/etianen/django-reversion
reverse-compare is just an extension of the reversion app. This gives us the comparability between the different reversions created by reversion. This is also used in the "history" page on the wiki to display what a user changed on the page.
Middleware classes is functionality that needs to happen on every request and response sent to and from the server.
MIDDLEWARE_CLASSES = (
...
)For example, the reversion has some functionality that needs to happen every time a registered object is changed or deleted. It's kind of a hassle to do this manually everywhere in the code where we change or delete an object. Therefor we have a middleware that does this functionality if needed on every request and response:
'reversion.middleware.RevisionMiddleware'Likewise, all the other middleware are simply functionality that for some reason needs to happen on some (or all) requests and/or responses.
python
ROOT_URLCONF = 'page.urls'
This line simply says: "Hey mr. Django, alle the valid URLs are located in the urls.py file inside the page app. If you get a request to an URL that do not match any of those, throw an error on them and tell'em to go away."
WSGI_APPLICATION = 'page.wsgi.application'This tells Django where it can find the WSGI-application (inside the page app, in a file called wsgi.py there is an object called "application"). WSGI stands for Web Server Gateway Interface, and is something Django and a webserver uses to communicate. Django needs this to talk to the webserver when the wiki is deployed (or when you run "python3 manage.py runserver"). Basically it works like this: The webserver gets a response, eg.: "GET '/view/akademisk_radioklubb.html' ". Then it says "Hey, WSGI-application, tell Django I need the file /view/akademisk_radioklubb.html". Then the WSGI-application says: "Yo, Django! The webserver needs some file called '/view/akademisk_radioklubb.html'. Know what the hell it's talking about?". Then Django respond: "Howdy there WSGI-applicating, long time no see! I don't have any idea what the heck it's doing, but I ain't got no file called that.". The WSGI-server then walks all the way back to the webserver: "Sorry bro, mr. Django didn't know anything about that file". Webserver: "Oh well, worth a try. Should probably throw them an error or something.. Thanks anyway WSGI-server!". WSGI-server: "Anytime". All of this of course happens within the span of a few milliseconds.
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
}
}This defines what kind of database technology to use when storing all of the data used in the project (all of the pages, the different versions, etc.). SQLite3 is an very lightweight database technology, but might be sufficient since we do not have that much data. We might also considering just using plain old MySQL, just because of all the available documentation that exist out there. We do not need any special database technology, just about anything will work. See the Django documentation for more info.
STATIC_URL = '/static/'This simply states that all the static files should be served under the URL /static/. It does not say anything about where the static files are located, just where it will appear to be to the enduser.
MARKDOWN_EXTENSIONS = ['extra', 'wikilinks', 'toc']
MARKDOWN_EXTENSION_CONFIGS = {
'toc': {
'separator': '-',
'title': 'Innhold',
'baselevel': 2,
},
'wikilinks': {
'base_url': '/view/',
'end_url': '.html',
},
}Here we specify the installed extensions of the django_markdown app, and some configuration of them. You can read more about the different official supported markdown extensions (including the one specified here) and their respective configuration here.
For topics not covered here, and more in-depth descriptions, see the official Django Documentation of the settings file.