| Age | Commit message (Collapse) | Author |
|---|
|
Those things are not really a configuration thing that changes, rather
they are part of how the code of the application works. As such, it
doesn't make too much sense to require those configuration values.
Instead, we now add those filters programatically.
This also ensures that the filters are the same between development,
production and testing environment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This cuts down on the code duplication and makes sure that we use the
same algorithm everywhere. It also keeps the view code cleaner.
|
|
This puts the handling of retrieving the right database object at a
single place, which makes it easier to use from the different routes,
and unifies the error handling (some places for example lacked the check
to see if the returned object is None).
It is also the first step to a better permission system based on
Pyramid's ACLs, as we can now implement those on the object. This will
make the code even better and even more uniform, as we don't need to do
the permission checks manually anymore.
|
|
The main issue was this: Our body has a slightly lower font weight of
300, so "bolder" works out to be 400 - which is a barely noticable
increase. The reason for this is that "bolder" (and "lighter") are
relative font weights, but they only work relative to certain
"breakpoints" - and 300 was just a notch below the next breakpoint of
400 [1].
By setting the font-weight of "strong" to 700 directly, we get a
noticable boldness increase instead, though we might tone it down just a
notch in the future.
In order to prevent font issues in the future, we've now also included
all proper variants of OpenSans, so that all font styles are available
to us, using the webfonts helper tool [2].
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight#meaning_of_relative_weights
[2]: https://google-webfonts-helper.herokuapp.com/fonts
|
|
This might need some fine tuning in the future
|
|
|
|
They shouldn't change that much (currently, there is not even a way to
change them from the web), and it saves a lot of data to cache the
megabytes of GPX data.
|
|
|
|
|
|
|
|
This prevents "weird" objects from lingering around. Now, if a user is
deleted, their tracks are also being deleted - which is good, especially
for the user's privacy.
For a more "graceful" closing of the account, we could implement a
strategy that first re-assigns the tracks to a different owner, and then
deletes the account. But that may only happen with the consent of the
user, and it is a work for future improvements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This looks way better than doing wonky space-separated things.
|
|
Supplying multiple inputs and retrieving them all is probably better
than the weird badge-1, badge-2, ... hack we used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We can just re-use the track's id, which also has the nice benefit that
both the cache and the track have the same id.
|
|
Using a weird custom preprocessor and saving the tags as a space
separated list in the database was not a good decision. A secondary
table is more in line with how databases work, will probably help us
with faster search later if we implement it (by creating an index for
it).
Additionally, this opens the possibility to have things like user-styled
tags (custom color), as we can save additional information in the tag
table.
|
|
|
|
|
|
|
|
|
|
|
|
Sooner or later, I'd like to have pylint running on the code in the CI.
It's better to fix errors sooner, than to be greeted with hundreds of
pylint issues once it will be turned on later.
|
|
|
|
|
|
|
|
|
