incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <jch...@gmail.com>
Subject Re: Implementing next and previous links
Date Tue, 02 Mar 2010 19:15:57 GMT

On Mar 2, 2010, at 11:11 AM, Saq Imtiaz wrote:

> Hi Sean! What a small world. Funny running in to you here! What are you
> using couchdb for?
> 
> Yes the goal is for the application to be self-contained within couchdb so
> that replication for instance, copies the application logic and the data.
> I've had a very nice conversation with jchris on #couchdb and he's
> essentially confirmed my feeling that if I want prettier links than using
> ?startkey type urls, I'll need to rewrite them clientside after performing
> additional queries.

Yes and no.

Start out by writing your application with ugly links. Then look at the _rewrite handler you
can add to design docs. This is not well documented yet (there is JS tests for it). It should
be able to make your URLs pretty.

Cheers,
Chris

> 
> If anyone else has different ideas on how to do this within the described
> constraints I'd be happy to hear them.
> Cheers,
> Saq
> 
> On Tue, Mar 2, 2010 at 20:03, Sean Clark Hess <seanhess@gmail.com> wrote:
> 
>> Hey Saq! It's been a while. How have you been?
>> 
>> Is an application layer out of the question?
>> 
>> On Tue, Mar 2, 2010 at 11:16 AM, Saq Imtiaz <lewcid@gmail.com> wrote:
>> 
>>> Hi guys. I'm getting to know couchdb with an aim to writing a "blog-like"
>>> application where you display one post at a time. Posts have a
>>> chronological
>>> order and each post has "next post" and "previous post" links.
>>> 
>>> I was hoping to get some input on the best way to implement these links.
>>> I've done a fair bit of reading on the wiki and mailing list archives
>>> (especially discussions around paging). I'm looking to create a couchapp
>>> where I can render the essential information as HTML in couchdb and only
>>> make additional requests from the clientside for comments. An additional
>> a
>>> consideration is that I'd like to be able to use the url rewriting in
>>> couchdb 0.11 to have "meaningful" links to each post, e.g.: /date/title
>>> (where title=docid)
>>> 
>>> What I've done so far is to give each "post" document an id which
>>> corresponds to its title and a numerical "date_created" attribute. I have
>> a
>>> view function that emits ([doc.date_created,doc._id],doc)
>>> 
>>> Then I load a specific page using myview?key=["201003021333","docid"]
>>> I suppose I can use the total_rows and offset to predict whether or not
>>> there should be next and previous links but I'm not sure if there are any
>>> hidden caveats here?
>>> 
>>> For the next link I can use:
>>> myview?startkey=["201002261927010000"]&limit=1&skip=1
>>> For the previous link:
>>> myview?startkey=["201002261927010000"]&limit=1&descending=true
>>> 
>>> Alternatively I could load the first page using
>>> myview?startkey=["201002261927010000"]&limit=2 and use the "next"
>> document
>>> retrieved to create the link to the next page.
>>> 
>>> However, this leaves me with a link to the previous page that is
>> impossible
>>> to rewrite to a /date/title type of format. Is there any way to work
>> around
>>> this or is this a limitation that has to be lived with?
>>> 
>>> My last resort would be to create "ugly" links using startkey query
>>> arguments serverside and then use clientside code to fetch the necessary
>>> information to change the links to have "prettier" href values. This way
>>> the
>>> static html served by couchdb has working navigation and the UI
>>> improvements
>>> are happening clientside.
>>> 
>>> Is there anyway at all to respond to a request for a specific document
>> (by
>>> doc._id) or other attribute with the document in question but also the
>>> previous and next document?
>>> 
>>> Many thanks,
>>> Saq
>>> 
>> 


Mime
View raw message