The markup for the album listing page and individual album page
were different enough that I decided to make them wholly separate,
but then this left the shared javascript in its own stupid file
unlike any of the other types.
So, I'm merging them as a huge jinja if-else, which is also dumb
but it feels better than all these separate files.
This will help keep the code on the pages focused more on the
page-specific stuff like form handling, and less on the raw api.
Plus, by having it all in one place, it can be cached
and also we can use any api from within any page.
Applied wrapping to the description <pre>s,
removed some css that referred to nonexistent things,
move some element tags inside the {%if%} that fills the contents.
I have finally found a pattern I like which is
function, function_callback, and function_form
for the backend, callback, and button handler respectively.
The javascript is very inconsistent between pages. I'm trying to
start using a consistent pattern where the api call is kept in a
separate function from the ones that buttons and input boxes
talk to.
Instead of embedding the entire tag list in the search.html template
every single time, this script loads the tags from the new,
cache-enabled endpoint /all_tags.json. Then we can use html5
datalists to create autocomplete forms on the search and photo pages.
I found that the strict heirarchy was not satisfying the situation
where one tag is the intersection of two others, but we can only
pick one as the parent
For example, does red_jacket belong under clothes.red_clothes or
clothes.jackets? A search for "red_clothes AND jackets" might
give us someone wearing red pants and a black jacket, so this
definitely needs to be a separate tag, but picking only one
parent for it is not sufficient. Now, a search for red_clothes
and a search for jackets will both find our red_jacket photo.
The change also applies to Albums because why not, and I'm sure
a similar case can be made.
Unfortunately this means tags no longer have one true qualname.
The concept of qualnames has not been completely phased out but
it's in progress.
This commit is very big because I was not sure for a long time
whether to go through with it, and so much stuff had to change
that I don't want to go back and figure out what could be grouped
together.
It was getting difficult to remember which of the normalizers
use None and which don't. So let's try to be a little more consistent
and just use empty sets, etc, so the caller can rely on receiving a
set instead of having to check for None.
Also renamed search parameter authors->author to be more in line
with the singular form of extension.
In order to achieve tag_musts, we break each of the musts down
into separate EXISTS queries for each of the matchable children.
Then we INTERSECT those, and finally do other filtering and
ordering as usual.
Previously they were relative to the directory from which the client
was launched, meaning it usually started with ./_etiquette.
Now it should be more portable and less tight.
By default, photos with searchhidden do not appear in the search
results. This allows a small number of representative images from
a large album to appear in the results, while the rest can be
found on the album's page.
The same effect could be achieved with a tag and forbid search,
but tag searching has much higher cost and it would be more difficult
to implement as a default behavior without requiring lots of special
checks whenever listing tags etc.
