The code in here is for the site's administrator to see a list of all
the users with an account with edit and delete options. There is,
also, a section to create new users (non-admin. accounts).
Just an extra check in amongst what's already there. If the username
the new sign-up attempt has entered matched one already in the
database, a message is relayed stating as much and redirects back to
the sign-up page.
The functions are helper functions for when dealing with
SQLite3. Because SQLite3 doesn't have a Boolean data-type, I have to
store the 'true' and 'false' values as integetes.
0 == false
1 == true.
The update part refers to the redirect when a database is found whilst
making a HTTP POST request, as part of the init-db
process (A.K.A. website's first run procedure).
The auth to nera change is because I didn't catch all of the moves in
a previous commit. The image I was running at the time still had the
auth version so it wasn't showing any errors. I spotted this one when
trying to run a new image.
The web package was already using code from some of these
packages. This commit moves some of the code in the web package into
one of the various referenced packages and also has 'web' utilise the
new features in those pacakges also.
The biggest shift is in how the alert-messages are handled (store in
ningle:*session* across HTTP requests) and how auth. is handled --
mostly the redirects functionality.
The main reason is so the constants defined in the status-codes
packages can use it. I've put the (HTTP) status codes in their own
package because they are a self-contained thing. I find it easier to
work with them this way.
nera is responsible for the database stuff which is not part of
Caveman2. The status-codes package is a list of constants representing
the various HTTP status codes -- with an explanation of what they are for.
I was having trouble trying to get hermetic and mito-auth to work
together. I decided to just use normal mito and leave hermetic to the
authentication/authorisation stuff.
There was snippets of code in the code I liked. I'm going to keep it
around for a bit to see if I can work some of it in to the new
code. I'm most interested in the deployment code.
I tried it and I find it easier to work with Caveman2. I didn't
realise this templating program is built around Hunchentoot -- whereas
Caveman2 builds on top of. So, I'm moving the code to back to Caveman2
-- where I originally started. It looks like a waste of time but the
knowledge of having a look at the other stuff has been helpful.
This script adds a user to the database based on it's inputs (prompted
for the person running the script). The intention is to add a user to
the database easier (especially on a live production server with just
the CLI).
https://github.com/vindarel/cl-cookieweb (for GitHub Repo. and
instructions).
The reason for using this is because it makes it easier to run the
website as a standalone thing. You don't need to link it up to
Quicklisp's /local-project directory. It has scripts to help you build
the binaries and to run the website (as a standalone) thing. I, also,
hadn't use this 'cookie cutter' program before so it's a good time to
get my feet wet.
The admin. backend for Django isn't as easy to get to where I want it,
compared to Caveman2. The trade-off is Common Lisp isn't a mainstream
language so it does reduce the level of ease other might have when/if
they join the project.
I'm going to try this with Python and Django first. Because it's not
my personal project, it might be better to use a language which is
more mainstream. It should reduce the 'Bus Factor'.
