I initially just wanted to work on that simple Panoramax feature, but
faced a bunch of bugs!
- one bad var remaining since whatever refactor (and no tests for this
popup template!)
- title was duplicated, since whatever refactor (and not tests for
this…)
- title text was in black on blue background
fix#2289
Let's add "nom" in OSM France and ANCT instances, then, to make users
experience smoother (a lot of imported data contains a "nom" column, and
no "name" nor "title").
In other words: fill in the "tags" input with the latest
typed expression.
Otherwise, when making tries with overpass imports, one have to
type it again and again (it's available through the autocomplete,
though, but it's not obvious and it's less friendly IMHO).
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
The last refactor of the save process (0fdb70ce66)
has introduced a bug: the save flow was not more stopped when a layer fail to save.
This ends with a broken UI, as the map is not dirty anymore, so the save button
is not active anymore, while at least one layer still needs to be saved.
Save can fail in two scenarios:
- there is a conflict (status 412)
- the server is down or as an issue (eg. disk is full)
I tried a more modest scenario (listening for status in map.save and
recallign the map save after a conflict), but this ended with calling
map.save uselessly even more.
So I decided to try this refactor, which also totally remove the useless
map.save we were sending at each save until now.
When finishing drawing a polygon/line, Leaflet.Editable will send
both `editable:drawing:end` and `editable:drawing:commit`. In normal
flow, we only need to listen to the later, and we only need to
listen for the former in the case of pressing escape while drawing.
And only this panel.
This was creating a weird bug, steps to reproduce:
- create a marker
- shift-click on the marker to edit the layer (so without explicitly
closing the panel)
- try to type the layer name: the panel would close
This is also because currently the schema and render() are too
dump, and when any `name` is changed then the `data` reflow is
called, while it should not when editing the datalayer name.
We want to:
- have more targeted schema
- have more specific reflow in render
But that's for other PRs!
fix#2232
A classified layer needs to have compiled the data to known its
classes/categories.
This commit review the way we build the legend: instead of creating with
the whole caption panel, we just set a container and we populate it
later. This opens the door for live changing the legend when editing the
layer.
But we have to clarify that "reactive" pattern at some point, as we have
some concurrent pattern laying around: the `render()`, which coupled
with the schema and this is nice, but for now it's a bit rough (changing
the whole UI each time); the `propagate` way, which is more specific,
but not coupled to the schema; the `dataChanged`; and the `onDataLoaded`
now, which is a bit different, as it's about the data being loaded, not
changed/modified, but for the DOM it may at the end be the same. Well,
food for thoughts…
fix#2232
A classified layer needs to have compiled the data to known its
classes/categories.
This commit review the way we build the legend: instead of creating
with the whole caption panel, we just set a container and we populate
it later. This opens the door for live changing the legend when
editing the layer.
But we have to clarify that "reactive" pattern at some point, as we
have some concurrent pattern laying around: the `render()`, which
coupled with the schema and this is nice, but for now it's a bit rough
(changing the whole UI each time); the `propagate` way, which is
more specific, but not coupled to the schema; the `dataChanged`; and
the `onDataLoaded` now, which is a bit different, as it's about the
data being loaded, not changed/modified, but for the DOM it may at
the end be the same. Well, food for thoughts…
fix#2097
cf #1500
This is an alternative proposal for #2097:
- adding the button near the "Filter" toggle was a bit ugly, CSS/HTML
talking, because this "Filters" box is a details/summary
- I thought that other needs could live in the same place: a link to
download the filtered/visible data, and a button to show the map data
extent
The "toggle all" button works this way:
- if one or more layers are shown, it will hide those layers
- otherwise it will show all layers
I've preferred not to change the button icon according to map state,
because I didn't find a reliable way to do so, thus I'm afraid to have
inconsistency, but I can't try harder if needed.
Related: I'm thinking of adding a "Download" button for each layers, as
it's a request that comes quite often.
@Aurelie-Jallut could you have a look ? :)
