Introduction to GeoNode development
NOTE If you have completed one of the previous training modules, you can keep using the same Virtual Machine deployed in the GN1 section Quick installation guide. If you are starting this module from scratch, you might want to install a Virtual Machine with datasets that are already configured and deployed. Download the Virtual Machine OVA archive named GeoSolutions-GeoNode-Training-VM-4.2.3-Initialized
This tutorial will introduce you to the GeoNode architecture, which framework it is based on, and what can be built upon it.
GeoNode development can be split into two major purposes:
GeoNode development is intended for improvements, bug fixing, and implementation of new features.
The customization of GeoNode is related to modification of the model, customization of the look and feel, and implementation of custom features.
GeoNode development
This kind of development is usually done directly into the GeoNode core repository, following the standard procedures of most Open Source communities (fork of the official repository, implementation in the fork, and then a pull request back into the original repository).
Implementing customization inside the core GeoNode code should be avoided if possible, because it will make it harder to upgrade GeoNode in the future. In fact, pulling official modifications into the customized code may create code conflicts that may need further work and that could be difficult to solve.
In the next chapters, we’ll see how to modify the code in the core GeoNode.
GeoNode customization
GeoNode is based on Django (a Web framework that will be introduced and detailed in the next chapter). Django organizes the code in various apps and makes ways to “connect” the apps available.
Thanks to this way of organizing code, you can create a customization for GeoNode as one, or more, Django apps. In this way your customization will be decoupled from the GeoNode core code, allowing you to update GeoNode (for instance, to import new fixes) without generating any code conflicts.
In the next chapters, we’ll see how to create and maintain a GeoNode project starting from a provided template.
Docker
GeoNode needs a set of external services to run, including a DBMS (PostgreSQL), a message broker (rabbitMQ), and a GeoServer instance. In order to develop, run, and test GeoNode you probably will need one or more of these services up and running.
As a developer or a frontend designer, you may want to focus only on a single part of GeoNode without dealing with all these different services.
Here comes handy Docker. Docker is a platform that enables you to separate your applications from your infrastructure. This means that you can run all the ancillary services needed by GeoNode without installing them directly onto your system, but have Docker run them in a sandboxed environment.
In the next chapters, we’ll see how to run a set of services handled by Docker.