I was adding messages as strings because that's how they get shown on
the web interface. But it's better to return the real exception objects
and have the interface deal with it.
This experiment of bringing Photos and Albums closer to parity in
search is going well so far. I have found some situations where it
is nice to only get albums back from search results.
There was always some semblance that two blank lines has some kind of
meaning or structure that's different from single blank lines, but
in reality it was mostly arbitrary and I can't stand to look at it
any more.
I'm currently running an experiment where albums are also included in
search results, but they don't cost you any of your limit parameter.
So the len(results) was often bigger than limit and tricking this
paginator into thinking we needed a next page when really we didn't.
This workaround can be undone when I decide how to make the album
results more official.
I've been thinking about this for a while but couldn't think of
the perfect way to implement it. I still haven't, so instead I'm
just starting with something and we'll see how to improve later.
At any rate, I can update the rest of the system to expect Albums
coming out of search so that if I ever have a better algorithm
everything else will already be ready for it.
For this first experiment, just any photos that are part of an album
will send that album out as a result. It doesn't even respect the
limit parameter, it's really just to see how it feels to use.
Alright, I got tired of confusing myself with the same-named
outer and inner package.
Keep in mind that every frontend implementation is supposed to be
its own independent project where etiquette is nothing but a
dependency. So the name backend is not ambiguous with the etiquette
backend.
2018-11-04 19:45:23 -08:00
Renamed from frontends/etiquette_flask/etiquette_flask/endpoints/photo_endpoints.py (Browse further)
