Part 1 - Getting started
Posted by pandorfer
on Feb. 1, 2017, 11:03 a.m. (last update April 24, 2017, 5:47 p.m.)
'django-generic-apps' resulted from the process of avoiding work. Or, to be more precise, django-generic-apps should reduce dumb and repetitive work. But isn't Django dedicated to the DRY principle (which stands for 'don't repeat yourself'? Well on project basis it definitely is. You create your model, derive views, filters, forms, and more from it, write a view templates, configure some URLs and you are done with a neat CRUD-application as the one described in the official Django tutorial. But when you are in charge of several projects, you have to do the afore mentioned steps again and again for each project. And then things start to get dumb, boring and repetitive. This is where 'django-generic-apps' step in.
Though before we go into detail a general remark: This series of HowTos serves first and foremost as some kind of verbose documentation of the django-generic-apps and not a precise step-by-step tutorial. So if you want to implement some of those generic-apps in your own project, you will need a basic understanding of Django so you can modify, tweak an adapt those apps to your specific needs. This will be necessary since all those apps described below were developed in the contexts of concrete projects and are therefore not (always) as generic as they could be. If you are looking for some really highly generic tool to bootstrap your project, please consider Cookiecutter Django.
What Kind of Apps?
In Django an app is NOT understood as full fledged web application (this would be a Django project) but more as a module, a library which provides dedicated functionalities or are responsible for certain tasks. And ideally such apps are build in a very self contained and generic way, to improve their reusability.
Probably the most useful app amongst 'django-generic-apps' is called webpage. It basically provides:
- a generic start page
- a generic imprint page
- a cookie consent pop up
- a social media share button
- and user authentication (log-in log-out)
This application is used in the following projects (by the time of writing this post):
As one could most likely guess by the app's name, this app can be used in projects which are dealing with 'places' where as a 'place' is an entity which can be located/described by its GPS coordinates. The app provides:
- a model of a place like entity with properties like: name, longitude, latitude or geonames-id
- an edit view which automatically tries to fetch possible geonames-id from the geonames-id-api and displays the matches on a map
This application allows to link/sync data from Zotero libraries with Django projects. Therefore it provides:
- a simple model of a bibliographic item with the properties like author, title, year, ... as well as property with stores the key or ID of this item assigned by Zotero
- a script which allows to import core data from Zotero items into the Django project
vocabs - nomen est omen - takes care of the controlled vocabularies in a project. It does so by providing:
- a data model very closed to SKOS
- an API to query the vocabulary and/or retrieve in JSON or as RDF/XML
- an interface to import/upload existing SKOS concepts from RDF/XML
- views to render those templates
- as well as demo data endpoints to make rebuilding custom made endpoints easier.
For the last three items in this list (world, blog, and iso639) the boundaries between app and project or service are not clear to draw any more because either of purpose or complexity of the app/project. "World" for example could be packed very nicely into a single application. But since this application deals with spatial data, it requires a PostgreSQL as database and some GIS libraries which are slightly tricky to install. Also, ACDH-OeAW intends to provide this application as a service (see) which ideally makes it superfluous to install this application into other projects. The same is true for iso639 which is an application/service exposing and API to query and retrieve ISO639 language codes. Most parts of the blog application (which is the core this HowTo-Blog could be kept self contained and therefore easily reused. But the implemented full text search adds an extra layer of complexity to the projects architecture which would require some thoughtful refactoring to keep this app as generic as possible.
Conclusion and Outlook
This was a quick tour-de-force through 'django-generic-apps'. In the following post we will build a sample Django project which will implement all those apps.
Comment/Edit this post on GitHub.
export blog text