Opened 12 years ago
Last modified 12 years ago
#112 closed defect (FIXED)
Previous / next navigation on media pages
|Reported by:||Jef van Schendel||Owned by:||Jef van Schendel|
We'll need a navigation area on the media pages to browse a user's media. We can start simple, by adding "previous" and "next" links. I don't have any idea to do this, so here's a humble request to anyone capable. Creating two regular links to move back and forward through a user's media would be great, then I can style them. To start with, they'll look `something like this <http://schendje.fedorapeople.org/temp/Screenshot-1.png>`_.
Change History (16)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Also worth reading that reply: :: Just watch out. If documents are inserted at the same time as they are being read, you could end up with partial results during newly inserted queries, and thus its not a perfect way to ensure you get all next set of records, as more could have been inserted with the same timestamp in the interim. For this, ended up needing to use capped collections and natural order with skip.. it was the only way to guarantee that pagination works exactly the same in every case, even while new data is pouring in from multiple clients. I don't think we can use capped collections, unfortunately..
comment:3 by , 12 years ago
A vague idea of how to solve this: - Instead of querying on say, timestamp greater than the current document, query on greater or equal to - Present document will be in that list. Find whichever document comes **immediately after** the present document. That should work and not be very intensive.
comment:4 by , 12 years ago
Currently a programming task. Setting to two hours estimated time just in case the above stuff is slightly confusing, but I think this should be pretty easy.
comment:5 by , 12 years ago
I'm confused whether our custom indexing solution alters how I should approach this problem relative to what I find in mongodb and mongokit docs
comment:6 by , 12 years ago
Chris suggested this pseudocode in IRC: :: # If there's just one entry at this time, we can use the "easy" next # and previous (if they exist) if mediaentries.find(same uploader, SAME time).count() == 1: try: next = mediaentries.find(same uploader, greater_than_time).sort(created time) except IndexError: #?? next = None try: prev = mediaentries.find(same uploader, less_than_time).sort(-created time) except IndexError: #?? prev = None # otherwise, complicated code else: next = None found_orig_entry = False for entry in mediaentries.find(same uploader, less_than_time).sort(created) if not found_orig_entry: if entry == original entry: found_orig_entry = True else: # we found the entry on the last round, so this one's it next = entry # and same for previous, in reverse direction Elrond suggested sorting on the objectID. Specifically, for the 'next one': :: ((time == current.time and id > current.id) || (time > current.time))
comment:7 by , 12 years ago
I have a functional branch here - [https://gitorious.org/\ :sub:`cfdv/mediagoblin/cfdvs-mediagoblin/commit/9c0fe63fadc848b5154c7c1d4b2ff72dd05bc1c6](https://gitorious.org/`\ cfdv/mediagoblin/cfdvs-mediagoblin/commit/9c0fe63fadc848b5154c7c1d4b2ff72dd05bc1c6) I made the needed links, and put some TODO comments in the spots I imagine will be filled as someone else makes it pretty. I don't like the code duplication in models.py, and I tried to move it out into the template but I couldn't use unicode there unless I added it to the global jinja2 environment, but even then the links didn't come out right. Perhaps I should make an internal function to encapsulate the repeated code. Feedback is most welcome!
comment:8 by , 12 years ago
Merged. I'm not entirely comfortable about not sorting on date and time.. I'm not sure we can guarantee things when there end up being multiple servers with multiple submissions happening, etc. But for now I suppose it's no huge deal. We can always commit that later. I'm not closing this, but I am moving it to 80%.
comment:9 by , 12 years ago
What's the failure scenario when multiple servers get involved? Also, this ticket still needs next, prev, next-greyed-out, and prev-greyed-out images instead of my place-holders
comment:10 by , 12 years ago
Failure scenario is you simply can't be sure that the previous/next in the order will be the same as the previous/next in the gallery, because you can't totally be sure they're sorted exactly on timestamp. Thanks for pointing out the missing placeholders.
comment:11 by , 12 years ago
|Milestone:||0.0.3 → 0.0.4|
|Status:||New → In Progress|
Alright, awesome. Time to make them look decent. Assigning to me and 0.0.4 targeted. Thanks Caleb!
comment:12 by , 12 years ago
I see re: failure scenario. I think synchronizing the prev/next ordering between the user page and the gallery is an additional ticket. Whaddyasay?
comment:13 by , 12 years ago
|Status:||In Progress → Closed|
I've styled the navigation buttons, so I'm closing the ticket. I think issue is specific/different enough to open a new ticket for. :) Thanks again, Caleb!
comment:14 by , 12 years ago
awesome, Jef! I can't wait to see/use it.
comment:15 by , 12 years ago
|Milestone:||0.0.4 → 0.0.3|
comment:15 by , 11 years ago
The original url for this bug was http://bugs.foocorp.net/issues/401 .
Note: See TracTickets for help on using tickets.