[GeoNode-devel] Practices on maintaining a geonode project, PR: "Align to GeoNode master 4.2.0"

[Florian Hoedt]

Thank you two for the insights, 
I think we should take some time and funding to enable a better development experience. Other projects make it easier to add to the core. Most of the time those other projects are not as complex as GeoNode though. Maybe we as developer community could articulate and define the most urgent issues and we (Thünen-Institute) will try to get funding to smoothen the path? 

Yours, 
Florian 
-- 
MSc Florian Hoedt 
Head Research Data Management | OpenData Representative 
Thünen Institute, Centre for Information Management 
Bundesallee 44 
38116 Braunschweig 

Tel: +49 531 596-1428 | Mobile: +49 162 92 50 275 
Fax: +49 531 596-1499 
Mail: florian.hoedt at thuenen.de 
Web: www.thuenen.de 

The Johann Heinrich von Thünen Institute, Federal Research Institute for Rural Areas, Forestry and Fisheries – Thünen Institute in brief – consists of 15 specialized institutes with socioeconomic, ecological and technological expertise. The Thünen Institute conducts research and policy advice related to rural areas, agriculture, forests and fisheries. 


Von: "Toni Schönbuchner" <toni.schoenbuchner at csgis.de> 
An: "Henning Bredel" <h.bredel at 52north.org> 
CC: "geonode-devel" <geonode-devel at lists.osgeo.org> 
Gesendet: Dienstag, 1. August 2023 11:55:41 
Betreff: Re: [GeoNode-devel] Practices on maintaining a geonode project, PR: "Align to GeoNode master 4.2.0" 

H Henning, 





Interesting approach. It seems even the blog you mention agrees with you when saying "[...] so we had to help all developers apply the filter. That is one downside: it’s totally quiet, so failures aren’t readily surfaced." :-) 




Exactly. It somehow always felt wrong. 
Especially Devs not familiar with Geonode had a hard time understanding what 
is going on ;)) 


BQ_BEGIN

However, I still assume changes in your working copy 

BQ_END


Correct, I also have to make some small tweaks in my working copy. 
But trying to keep them as simple as possible: 


BQ_BEGIN

- INSTALLED_APPS 

BQ_END


I did not touch settings.py except having the following in the end: 

# custom settings 
try : 
from .my_custom_settings import * 
except ImportError : 
pass 

Doing so I can extend and override what ever I need like INSTALLED_APPS, but keep the rest of settings untouched. 
Of course only things get into my_custom_settings that cannot be configured via .env anyways 



BQ_BEGIN
- docker/-compose files 

BQ_END


Similar as with settings I do override certain parts with a custom compose file 

docker-compose -f docker-compose.yml -f docker-compose-custom.yml up -d 

[ https://docs.docker.com/engine/reference/commandline/compose/#use--f-to-specify-the-name-and-path-of-one-or-more-compose-files | https://docs.docker.com/engine/reference/commandline/compose/#use--f-to-specify-the-name-and-path-of-one-or-more-compose-files ] 

Doing so docker-compose.yml can stay as 



BQ_BEGIN

or requirements.txt 

BQ_END


Good point! I’ve just changed it and left a comment before my changes. 
But I guess it should also work to mount your requirements into the container 
and override the start command a bit: 

entrypoint: ["/usr/src/geonode/entrypoint.sh", "bash", "-c", "pip install --no-cache-dir -r custom_requirements.txt && uwsgi --ini /usr/src/geonode/uwsgi.ini“] 

(Untested, and leaving a comment in requirements.txt might be cleaner in that case ;) 



BQ_BEGIN

These changes can be kept at a minimum and probably in a local branch, of course. Did you also try different approaches with regard to customizing geonode-mapstore-client, or do you prefer programming a completely different UI (probably this depends ;-))? 

BQ_END


To be honest, I have blocked adaptations for clients here as much as possible. Mainly because the reactive part of mapstore2 doesn't make it easy to develop (but that's due to my lack of knowledge). 
Also maintaining a fork is something I like to prevent. 

In some cases I have developed small custom viewers that only have geonode as a data provider. 
In one particular case, I decided to listen for WFS requests, process them as needed and create some DOM elements. This is of course a very messy solution as the virtual DOM should not be touched. But in this case it could be accepted and I avoided a custom build ;) To get the idea. 


// Catch WFS request 
var elements = []; 
(function() { 
var origOpen = XMLHttpRequest.prototype.open; 
XMLHttpRequest.prototype.open = function() { 
this.addEventListener('load', function() { 
if (this.responseText.includes(’something')){ 
window.items = JSON.parse(this.responseText); 
do_something() 
} 

}); 
origOpen.apply(this, arguments); 
}; 
})(); 


… 

// Create the button that opens the compare tool 
waitForElm("#drawer-menu-button").then((elm) => { 
console.log(„mapstore is ready“); 
// I guess there is a mapstore event we can listen on ... 
drawer = document.getElementById("mapstore-drawermenu"); 
var i = document.createElement("i"); 
i.classList.add("bi", "bi-arrow-left-right", "switch_icon"); 

var _button = document.createElement("button"); 
_button.setAttribute("id", "compare_button"); 
_button.setAttribute("data-bs-toggle", "offcanvas"); 
_button.setAttribute("data-bs-target", "#offcanvasRight"); 
_button.setAttribute("aria-controls", "offcanvasRight"); 

_button.appendChild(i); 
_button.classList.add( 
"square-button", 
"ms-drawer-menu-button", 
"btn", 
"btn-primary" 
); 
drawer.appendChild(_button); 
}); 

and so on. Again this is of course a no no ;) 

Hope this helps, 

Cheers 

Toni 


_______________________________________________ 
geonode-devel mailing list 
geonode-devel at lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/geonode-devel 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geonode-devel/attachments/20230801/da2ec80d/attachment-0001.htm>