Skip to content

GeoNetwork UI and microservices codesprint December 2020

Jump to bottom Edit New page
François Prunayre edited this page Jan 5, 2021 · 25 revisions

When & Where?

  • 14th to 18th December
  • The sprint will be remote

Who?

Monday-Tuesday

  • Francois - full week
  • Jose - about 2 days

Wednesday-Thursday

  • Pierre - 2 days
  • Florent - 2 days
  • Laure-Hélène - 2 days
  • Paul - about 2 days
  • Michel - about 2 days

Sponsors

Agenda

The main idea of this sprint is to define a common approach for UI apps and set up the building blocks to have a consistent experience when using GN-UI and GN-Cloud.

We have 2 types of apps:

This situation is quite similar with current apps - the angularjs app and the formatters producing HTML (+ the "no JS" UI). Formatters, if JS is loaded can have some dynamic elements eg. related resources, humanize dates Formatters link to the AngularJS app "access to the portal" and some predefined search eg. click on keyword. See https://apps.titellus.net/geonetwork/srv/api/records/64b34cd9-05b4-4e18-8e7b-15394d3fdb5c

Currently what is shared:

  • CSS config from admin
  • UI config from admin
  • HTML is not, header and footer limited in formatters

Can we improve that situation and navigation from one to another? Is permalink for a record, the formatter (ie. the OGC API Record landing page)? or the JS app.

Can we share resources in both app?

Templates that can be used in services producing HTML (eg. OGC API Record) and GN-UI components (https://github.com/geonetwork/geonetwork-microservices/issues/17). It is required to share design rule to make user experience consistent.

Themes

Can we create a theme? How?

In GeoNetwork 3 and 4, there is some kind of skin/theme which is composed of:

  • Header
  • Footer
  • CSS variables?

Is this something to keep and improve?

Resources:

UI Configuration

GN-UI will allow developers to more easily create custom apps with components, "a sort of GeoNetwork Lego". BTW, with portals and custom UI config in v3 and 4, quite some projects are using it to easily customized the main app.

  • Should we reuse part/all of GN UI config in GN-UI main app? (we already use the facet config)
    • + can allow adoption of GN-UI for simple use case at early stage
    • + will help transitionning from GN to GN-UI
    • - GN UI config is maybe not perfect - "too complicated", "too many things", "not enough"
    • If we use it, webcomponents should also be configurable directly with simple parameter

How to use GN-UI in GN-Cloud?

Service producing HTML may want to embed GN-UI component.

Use cases:

  • in the landing page a component rendering the bounding box of the record in a map, the data (eg. WMS) of the record in a map => Create a record-data-viewer component ?
  • in results, display humanized date based on UI configuration?

How to do?

  • Specific build? How to init component? Do we have to use only WebComponents?

GN-UI

New questions:

  • i18n / Loading multiple files
  • i18n / Duplicated keys on extraction
  • i18n / Organize in transifex
  • i18n / Clean up keys eg. app.context.name

GN-Cloud

  • Discussion on current status?

OGC API

  • Clean up exception and use multilingual error
  • HATEOAS or not ?
  • Model for index document
  • Logging

Logging

Fix log in tests (make travis fails)

  • Setup log level for tests. It looks like adding @SpringBootTest in AuthenticationTest + test/resources/bootstrap.yml with logging.level.*=ERROR set up log for spring boot test but it is probably not needed. Check how to init spring test only. application.properties does not look to be taken in account
  • Check how to use https://projectlombok.org/features/log
  • In ElasticSearchProxy use it for logging in HandleRequest in debug mode ES request sent, status code and errors. Same for auth?
  • Write a short guideline in README if any recommendations needed

GN4 Tasks

Summary

  • Facet improvements

With this experiment, we also identified area of improvements for web components :

  • 2 identical web components in the same page are sharing a state - this needs improvement to be able to scope web components to a particular search. It complexifies the packaging as it looks like we need to pack all the components used in the same page in the same component.
  • Web components are configured using attributes in the element eg. filter=”forest”. Those attributes can be manipulated by host page and the web component has to listen to those changes and adapt its state

The second topic aims to improve the catalogue availability and tackle major issues for the future of GeoNetwork. The main topic this month was the implementation of OGC API Records which is the successor of CSW.

  • Output format

    • Add pluggable output format using MediaType negociation
    • HTML rendering improvement
    • Test JSONLD output format
    • Test PDF output format

  • Security

    • Improve JWT (JSON Web Token) to exchange user details between services
    • Plug authentication in search service to build permission filter

  • Multilingual error message

  • Logging system and guideline

  • Continuous Integration - setup github actions to build and test the system.

  • Standalone mode deployment and spring boot packaging to be able to deploy OGC API records as a service next to a GeoNetwork 4 instance.

If you have some comments, start a discussion, raise an issue or use one of our other communication channels to talk to us.

Welcome to the GeoNetwork project!

Project Steering Committee

How to contribute

GeoNetwork cheat sheet

GeoNetwork website (external)

GN3 public implementations

Clone this wiki locally