This report describes a web-based, semantically-enhanced debate forum. The user is able to browse topics, and after creating an account, can create a topic and participate in debates. The application is designed to be used on a computer or a mobile device.
The application is to be implemented as a web application in HTML, TypeScript, Sass, and Python, using the Flask framework. For development purposes, the application will use the built-in Webrick server provided by Flask, and SQLite3 as a database. For a real deployment, the application would need a production-ready server as well as a production-ready database, such as PostgreSQL.
I will be creating a database schema for the application. Although the specification does not require using HTTPS for communication with the server, in a real deployment this would be a requirement.
The functionality provided by the application is listed below, together with the structure of the implementation.
This will be part of the site's landing page. When a user requests the root URL, a database query will be performed to fetch the names and details of the first 20 topics. These will be passed into a template which will generate an HTML table listing each topic's title, creation date, number of comments, and the date of the last comment. The listing will act as a link, taking the user to the topic's page, which will contain the topic ID as part of its path (e.g. /topic/3
).
This will be a page which displays the topic's title, creation date, and all posts so far.
A side-bar will contain jump links to each claim, and (for logged-in users) each comment within a chain will have a button to start composing a reply. The reply will be categorised depending on whether it is a reply to a claim or a reply to a comment; if it is a direct reply to the claim, it can be:
If it is a reply to an argument comment, it can be:
If it is a reply to a clarification comment, it is automatically marked as clarification.
Additionally, for logged-in users, a button will be available to create a new claim, which may relate to any number (including 0) of the existing claims - as either opposed or equivalent.
Many of the routes on the site will be protected by a logged-in requirement. If a user tries to access a protected route, they will instead be redirected to a special ‘log in to access this content' page. The user will be able to log in using a username and password.
Sessions will be represented using Flask's built-in session management, which stores the user's data in a cookie. The session will be initialised when the user logs in, and destroyed when the user logs out and will contain the datetime when the user logged in as well as their username.
Upon accessing any page of the application, if the user's session is more than 30 days old, it will be destroyed and the user will be logged out (and redirected if necessary). Otherwise, the user's session will be updated with the current datetime.
When the user attempts to log in, the API route will look up the username in the database; if it is not present an error will be returned; if it is present, then the server will use the hashlib.pbkdf2_hmac
function, in combination with a salt extracted from the hashed password, in order to hash the user's password, and check that the hashed password matches. If found, a session will be opened with the user's username and the current datetime as the session data, and (if applicable) the request will be redirected to the route that was originally requested. Otherwise, an error will be returned.
When the log out API route is used, the user's session will be destroyed and the user will be redirected to the home page.
If the user signs up for an account, the requested username will be checked for presence in the database; if it is, an error will be returned. Otherwise, a random salt will be generated and the user's password will be hashed using the hashlib.pbkdf2_hmac
function. The salt and the hashed password will then be stored in the database.
This will be an option on the site's home page for users who are logged in. When a user clicks the “Create new topic” button, they will be taken to a page where they can enter the topic's title and initial claim. When the user clicks the “Create” button, the data will be sent to the server, which will create a new topic in the database and redirect the user to the topic's page.