Tags on photos can now have timestamps, so that if you are tagging
a video or audio you can reference a specific moment with your tag.
In the interface, this means the tag is clickable and seeks to that
point in the media.
For the user interface, I am finding I need to move away from jinja
for the object cards because it is too much hassle to keep the code
for jinja-based cards for static rendering and the js-based cards
for dynamic rendering in sync. Rather than write the same cards in
two languages I can dump the JSON into the script and render the cards
on load. Which makes the static HTML worse but that's what the JSON
API is for anyway.
I've moved the thumbnails around many times over this project
and hopefully it doesn't happen too many more. Once the database has
tens of thousands of items, the thumbnails start to become the biggest
headache on the disk. Backing up, restoring, and sharding files per
directory are slower and more effortful with separate files. In the db
means the db is a larger file, but this is disk space that was already
getting used anyway. Now it's simpler and has atomic transactions.
The initial motivation for this was to make the "more_after_limit"
feature, which would help the UI to not show a next page button when
the number of results was exactly equal to the limit.
However, in order to surface this more_after_limit status using only
the old search generator, it would have to be a special yield at the
end. I was getting tired of the special yields like give_back_params
at the beginning and warning_bag at the end, and this would be worse.
There is a lot of sideband information about the search that is now
more easily accessible when the search is its own object.
voussoir