Constraints: GUI - create custom tab (GeoNode)

[etj]

We need a way to create a brand new tab in the editor page, for handling custom elements. Such elements shall be defined in django apps that need editing for customized fields.

The elements in the tab will:

• display the current values of the customized fields
• allow the editing of the values
• return back the values of the fields in order to be persisted in the db
• tell if the field content is valid or not, in order to let the editor know if the metadata editing is complete

e.g. we have an istance of LayerRNDT class, which is 1:1 with Layer. In this tab we'll be editing the properties of the LayerRNDT instance.

Please note that the fields editing could be quite complex (also allowing interdependencies between fields), so the whole handling should be implemented in the custom app.

[mattiagiupponi]

@etj as decided together, this part will not be implemented in Geonode, but we use the mechanism of override that Django gives us.

For instance, I cloned the view responsible for the metadata wizard by adding the new tab.

Since the requirement is changed, is still required to have a sort of configuration for customizing the fields? or it enough to define the form with the wanted data for rndt in the app?

Just a note, all the bullet's point defined in the issue, will be managed by Django form

[etj]

If by overriding averything is already in palce, of course no configuration is needed.

@afabiani is this implemention in line with previous customization? is it ok as implementation at all?

[mattiagiupponi]

@etj @afabiani in a nutshell:

• Template: The template follows the mechanism provided by Django, in few words, the app will have the same structure of the statics/template files of the original app. While rendering, Django will scan the INSTALLED_APPS, TEMPLATES, and STATICFILES_FINDERS by taking the first occurrence (the orders inside those settings is important!) to decide which is the template/static to be used in the app. If our RNDT app comes first, will use the custom HTML/statics
• View: The view is a bit different. In the urls.py of the RNDT app, I'm going to add as the first occurrence of geonode's urlpatterns the URL that I want to override by changing the view that will handle that specific request. Django allows multiple URLs because it takes as valid as the first one defined in the list. The code will be:

from geonode.layers.urls import urlpatterns
from django.conf.urls import url
from rndt.layers.views import layer_metadata

urlpatterns.insert(0, url(r'^(?P<layername>[^/]*)/metadata$', layer_metadata, name="layer_metadata"))

Pros and Cons. Follows a table of some pros and cons of this approach

Pros	Cons
No changes on Geonode master required	Code duplicated between Geonode and the app
Easy customization	template/ statics, in the app needs to be updated to Geonode master (if required)
No boilerplate added into Geonode
Fast PR feedback (is internal code)

If the mantra is to keep Geonode as much lightweight as possible, this could be a good approach

[afabiani]

@etj @mattiagiupponi should those additional metadata be shown on the layer details also or just on the CSW outputs? How the pycsw will be able to get the additional metadata from the auxiliary class?

In general I would prefer to have some sort of extension point into the current wizard. Is there a way to reach a compromise and extend only some blocks instead of rewriting the whole template?

[etj]

In the custom tab we'll handle:

• AccessConstraints (#15, #18): 2 fields (gmd:accessConstraints, gmd:otherConstraints). RNDT handles these 2 fields in a different way than the default one, so we have to replace GeoNode controls for them (#16). The original class/db model already includes them. We'll customize RNDT own XML template to include them (#19). Being exisiting fields, they should already appear in the layer details.
• UseConstraints: 2 fields (gmd:accessConstraints, gmd:otherConstraints- same as above, but with a different parent element). pycsw does not need to query these fields, we'll include the content in the XML document only. No plan to include these info in the layer details has been made.
• Spatial resolution: a numeric field (#22) to be added in this new tab (#23). pycsw does not need to query it, but we'll include the content in the XML document (#24). No plan to include these info in the layer details has been made.

[mattiagiupponi]

Regarding the templates, we are not replacing the whole Geonode's HTML, but only the files needed for this project (we are talking about 5/6 files. With this mechanism, we will override ONLY the files required for this issue, not the whole template

[afabiani]

@mattiagiupponi yes, I understood that we are going to replace few files. I was wondering if we can avoid rewriting the whole template by placing some template blocks to extend the original one instead, don't know if you see my point.

[mattiagiupponi]

I see, I need to analyze if the part that we need to replace in geonode is ready for the Extending an overridden template that Django gives us. After fixing the PR, I'm going to analyze if is possible

[mattiagiupponi]

@afabiani @etj After some analysis, here are the results. Overriding only a block of the code (usually) is possible, but looks like that, in this case, is not applicable.

At the moment we need to override the following files to implement the rndt features:

layouts/panels.html
search/_search_content.html
search/search_scripts.html
static/geonode/js/search/search.js

Django permits the override through the {% block %} tag, but due to the lack of blocking tags in the geonode template, this looks like a bit over-effort. I'll go a bit into detail.

We need to add a new facet on the left sidebar, named Pubblica Amministrazione. In order to add this new facet, I need to edit in layouts/_search_content.html the <div id="slide-pane"> by adding the new page {% include "search/_pa_filter.html" %}. The layouts/_search_content.html is contained in a block-tag called {% block body_outer %} in this file search/search.html, so I need to extend the code in the app with the following code

{% extends "search/search.html" %}
{% block body_outer %}
custom HTML template
{% endblock %}

The problem is that _search_content.html does not contain only the HTML template regarding the sidebar, but contains also other HTML that I need to rewrite in my custom app in order to let geonode works for example:

{% include 'base/_resourcebase_snippet.html' %}
{% include 'search/_pagination.html' %}
{% include "_bulk_permissions_form.html" %}
{% include "search/_sort_filters.html" %}

I take this as an example, but all the other files follow the same behavior. In conclusion, normally is possible to override just a partial part of the code, but in this case instead of change Geonode in order to add new {% block %}, is more practical to override directly the HTML ( by overriding the include ) Any thoughts?

Hope that the analysis is clear, any comment is appreciated

[giohappy]

@mattiagiupponi what if we add blocks wherever custom / additional elements are needed for RNDT? They could be used by other customizations too. What I mean is, for example, add a {% block additional_filters %} inside the _search_content.html, and so on.

[etj]

Since in this project there will be probably other customizations of this kind, it may be a good idea to create a new branch in the geosolutions fork of geonode with all of these new blocks in the templates.
We'll then create a PR at the end of the work, which will include all these changes.