-
Notifications
You must be signed in to change notification settings - Fork 1.1k
GNIP 30 Split out geonode.maps into 2 modules
It is proposed to split the geonode.maps module into 2 separate modules: geonode.data (or geonode.layers) to handle all interactions with data itself, and geonode.maps to handle the maps. This reorganization would be used to reorganize each of the new constituent files (models.py, views.py etc) more logically (similar or related methods together) and to add docstrings for all methods in the process.
In the long run, it makes sense to be able to use the geonode.data module on its own without providing maps functionality, as well as potentially the possibility to run the geonode.maps module without the geonode.data module and rely only on external OGC services. It's not required that we can do either of these now in the context of this GNIP, but it is desirable to consider this as we implement this GNIP.
Jeffrey Johnson
2.0
For Review and Comment
Files like geonode/maps/views.py is quite large and is fairly disorganized (similar or related methods are not grouped as well as they should be). This makes it difficult to navigate and thus daunting for developers who are new to the codebase. It makes sense to divide this large module into 2 separate modules that handle each of these blocks of functionality separately. Its desirable to do general reorganization in the process and to add docstrings as well.
Split the geonode.maps module into 2 separate modules.
This is an extremely far reaching change, and issues like providing migrations and trying to preserve backward compatibility are going to be difficult to wrestle with. It makes sense to try and solve these issues as they come up and iteratively. Its also possible that we just schedule this for a GeoNode 2.0 release that is known to be backward incompatible and provide an alternate way to migrate a site from 1.x to 2.x
The existing unit test suite will have to be refactored as part of work under this GNIP. At a minimum, the tests should continue to pass once migrated. This will be a good opportunity to bulk up the unit test suite or at least mark untested methods as important for creating new tests for. Perhaps we can use a 1-3 distinction with 1 being critical for testing, 2 important and 3 less important.
Do nothing.