Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of ryan.ramage@gmail.com
 designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <508968F3.9020304@berjon.com>
References: <DB0D8538-70A4-4683-B29B-846807A49F46@berjon.com>
	<FB65D33B-C416-4B04-9557-307DB683D566@calftrail.com>
	<508968F3.9020304@berjon.com>
Date: Thu, 25 Oct 2012 10:41:40 -0600
Message-ID: 
 <CAL-h1aQO5EDr-VJChNoDbwWjaGo2bXuTLog5k6o6SARSwDZ10Q@mail.gmail.com>
Subject: Re: Rewrite inside of a path segment
From: Ryan Ramage <ryan.ramage@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Wow, I like the idea of a rewriter function. It does add a lot of
power. Some things to consider...

I know others had rewriter rewrites in mind, namely benoit and jhs.
Would be nice if they thought this was inline with their ideas. Just
if we introduce it now like this we want to make sure its compatible
with the ideas.

Can you add the function as part of an array of rewrites? maybe like this:

rewrites : [
   {from : "/something", to : "/somethingelse"},
   "function(req, path) { ...}"
]


If moved ahead, I also would want to just have a check on
erica/couchapp tools to make sure could handle this syntax. No one
likes writing js functions inside of strings in a json file :)


On Thu, Oct 25, 2012 at 10:29 AM, Robin Berjon <robin@berjon.com> wrote:
> Hi Nathan,
>
>
> On 19/09/2012 22:24 , Nathan Vander Wilt wrote:
>>
>> On Sep 18, 2012, at 1:16 AM, Robin Berjon wrote:
>>>
>>> The problem is that I need a rewrite that invariably accepts
>>> parameters that don't fall at the / boundary. Typically:
>>>
>>> { from:   "/blog/*" ,   to:     "../../blog.*" ,   method:
>>> "DELETE" }
>>>
>>> And that doesn't work. It just invariably encodes the * or :id, or
>>> whatnot. Have I missed something? I of course could simply expose
>>> another ID for DELETE or ugly IDs everywhere, but that completely
>>> defeats the point of having rewrites in the first place.
>>
>>
>> You have not missed anything. The problem is that you're wanting a
>> rewrite doesn't fall on / boundaries, and the simplistic rewrite
>> handler does not support this. I wish that rewrites were implemented
>> in JavaScript instead of this one-off metalanguage, but my dreams
>> aren't much practical value to you right now ;-)
>
>
> As a matter of fact, they are :)
>
> It took me a little while to get back to you because I liked your idea of
> having the rewrite work from JS. So I foolishly picked up an Erlang tutorial
> and went on to implement it. You can find the pull request at:
>
>     https://github.com/apache/couchdb/pull/38
>
> Here's a quick description of how it works:
>
> """
> Alternatively, the rewriting can be performed by a function. It is specified
> as follows:
>
>  {
>      ....
>      "rewrites": "function (req, path) {
>          // process the request, and return the rewrite
>      }"
>  }
>
> The function is called with the request object and a path string. The latter
> contains whatever path is left after removing everything up to _rewrite/.
>
> Which rewrite takes place depends on what the function returns, which can be
> one of three things:
>
>   - false, or a falsy value: indicates that the rewrite could not be
>     performed. This translates to a 500 error.
>   - "a/path": causes the rewrite to that path to take place, with the
>     original method being kept.
>   - { path: "a/path", method: "FOO" }: rewrites to that path and changes
>     the method to the one provided.
>
> Rewrite functions are meant to be devoid of side-effects and one should
> write under the assumption that they are being cached.
> """
>
> There's a bit more information given in the pull request, and in the tests.
>
> I've only given it a cursory run yet but so far it works pretty well. I'd
> appreciate comments, screams, jokes, etc.
>
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon