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.
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.
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.
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'.