Around 2 months ago I found myself wanting some kind of way to administrate the database of my project, which is based on prologue. I also really missed the way the Django framework did it.
So I pretty much just came around to doing it myself, which was only really possible thanks to leveraging norm. Thanks to norm providing me with a generic and flexible way to interact with the database I could do basic CRUD interactions with the database. I only really needed to be able to generate HTML forms for create/delete/update pages, be able to receive and transform the form-output as necessary and then trigger such a create/update/delete operation via norm. All of the code that performs these operations is essentially generated at compile-time, meaning the codebase consists mostly of a lot of generics
The way this works is that Snorlogue provides 2 procedures that are relevant to the user:
This way you have access to the following pages:
Snorlogue by default can deal with the usual suspects of nim types except for enum and range. For those and any other custom datatypes you'll need to define procs that tell snorlogue how to convert a model-field into a FormField instance, as well as how to parse a string from an HTML Form into the provided type.
The URLs that the routes all have are somewhat fixed, but you can customize the prefix which is "admin" by default (e.g. normally a URL is, for example "/admin/overview/", you can customize that to be, for example, "/myAdmin/overview/"). Further you can tell Snorlogue to execute specific procs before or after performing a create/update/delete operation (think Django Signals). As for how to authenticate this, this is left to the user as you can provide middlewares that will be attached to all routes that Snorlogue attaches.
In terms of dependencies this uses:
An SQL Page that allows you direct DML access to the database. Just enter any SQL query you want and you'll get the output displayed.
Isn't this a bad idea for security?
With my current knowledge levels, I'd say it depends.
By and large I consider it equivalent to having database access if you have access to the admin area.
Naturally you can of course try to limit database access by only registering non-critical models, but that feels insufficient. If somebody with in the admin area should not be able to see data from Table X, then the database-user that is being used should not have access to Table X in the first place. So the place to limit access should be the database-administration itself (assuming you use postgres).
However, for sqlite that's not an option and I did not consider that one in particular, I'll need to ponder whether that should mean removing it entirely or not. Luckily removing isn't really all that hard I guess.
Congratulations on the release! Happy to see Prologue growing an ecosystem. And proud Norm helped with this effort.
Have you used Snorlogue on production yet?