merge pagination pages into normal catalog route

[MoralCode]

The pagination.html template seems to duplicate code with the catalog page (specifically the macro for rendering things - which is also in the header.html template)

also it seems like the page is mostly blank (see https://tunnelvision.csh.rit.edu/page?p=1)

this PR removes it and instead moves pagination into the catalog endpoint/templates (which it already has support for if one hardcoded reference is changed to be dynamic)

[wilsonmcdade]

Love the idea! I tried testing it though and the pagination doesn't work (getting a 404 on /page). The reason for this is we're using htmx to dynamically add elements to the page as the user scrolls. So if a muralcard has paginated==True a bit of htmx magic is added to the element that queries page?p=<...> for the next set of murals. That's the reason for the /page route. Basically if this scheme for pagination is kept then there will need to be a route that serves the next page of murals

[MoralCode]

The reason for this is we're using htmx to dynamically add elements to the page as the user scrolls.

i saw htmx stuff in the code but didnt know how it worked or what it was for (i.e. this needs to be documented better)

I feel like a clean way to re-fix infinite scroll with the current, merged catalog page is to just have a more=true URL param that causes the blank pagination route to be used, rather than the full catalog page template

Would that work?

[wilsonmcdade]

Yeah I think that would work

[MoralCode]

i found a way to deduplicate the jinja macro for defining the mural card too

[MoralCode]

it would REALLY help backport things if there was a defined code style

[MoralCode]

(also ended up solving the problem by simply checking for the presence of the p parameter to detect pagination