couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Goodlad <>
Subject Re: Implementing next and previous links
Date Tue, 02 Mar 2010 21:56:26 GMT
On Wed, Mar 3, 2010 at 6:35 AM, Saq Imtiaz <> wrote:
> On Tue, Mar 2, 2010 at 20:15, J Chris Anderson <> wrote:
>> 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.
> I should have been more careful in my choice of words Chris. The _rewrite
> handler can definitely make the URLs prettier for the previous link for
> instance, by mapping myview?startkey=["
> 201002261927010000"]&limit=1&descending=true to something like
> 201002261927010000/previous/. However note that this URL still references
> the "current" document and doesn't provide context for the page that is
> loaded when you click it. This also means that if a user then bookmarks said
> page, that URL might lead to a different document in the future if the order
> is changed.
>  What I haven't found a way to do is end up with a /date/docid/ type of URL
> for the previous post where the date and docid are both attributes of that
> previous post. Unless I've missed something significant the _rewrite handler
> can't do this as it provides simple mapping between different URL paths and
> can't perform any queries to the database to determine the appropriate
> document id for instance.

Why not reference the next and previous docids within the doc itself
(ie: a doubly-linked list)?


View raw message