We often need to compute the text/icon constrast color, but often
the element is not yet in the DOM, so we can't get the background
easily. Let's have a fallback for that instead of trying to have
"load" events everywhere.
While working on a helm chart, we do not control the creation of the db
URL, which use "postgres://" instead of "postgis://", so Django does not
set the correct engine. So let's be explicit here.
While working on a helm chart, we do not control the creation of
the db URL, which use "postgres://" instead of "postgis://", so
Django does not set the correct engine.
This also tries to rework a bit the "reflow" process, which how
to edit the UI when something changes in the data.
The idea is to build the whole HTML, then:
- the `propagate` method tries to change the UI with targetted CSS
selector, but anywhere
- while `render` hide/show some elements
This is not the destination, but just another step. We certainly
need to refactor the SCHEMA to make the next step (as we want to associate
some data change to UI change).
Side note (for another PR I'd say): this usually occurs on a non saved
map, but in case the map already exist and is in sync mode, should we
sync each property (safer but one call per property) or the whole
properties object (lighter, but may override unwanted things in remote,
and currently there is no method to do so).
Side note (for another PR I'd say): this usually occurs on a non
saved map, but in case the map already exist and is in sync mode,
should we sync each property (safer but one call per property)
or the whole properties object (lighter, but may override unwanted
things in remote, and currently there is no method to do so).
This make it possible to synchronize datalayers before their creation on
the server, allowing at the same time to solve issues related to them
not being saved (e.g. duplication of geometries)
We use the DataLayer._referenceVersion to track if a DataLayer has been
saved on the server.
After a save, the _referenceVersion is synched with other peers.
To pass the reference version from the server to the frontend, we have two
options:
- use a header
- populate the `options.version` field
In the case of a GET on a Datalayer, we could not use the `options` scenario
because:
- the value in the file is not up to date (it was the value the client has
before the save)
- the python cannot change it on the fly, as the file is served by nginx
So we decided to keep using a header. But on the map view, we load all
datalayers metadatas in the map options, so here we cannot use the header
scenario, so in this specific case we had to populate `options._referenceVersion`.
At the same time, we also changed:
- Umap.options.umap_id => Umap.id
- DataLayer.umap_id => Datalayer.id
- fixed the version number returned by DataLayer.version_metadata
