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.
Bumps [uwsgi](https://uwsgi-docs.readthedocs.io/en/latest/) from 2.0.27
to 2.0.28.
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
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.
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!
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…
