[erlang-questions] Pattern-matching function?

[anders conbere]

On Thu, Oct 30, 2008 at 12:28 PM, Steve Vinoski <vinoski@REDACTED> wrote:
> On 10/30/08, anders conbere <aconbere@REDACTED> wrote:
>>  To illuminate a bit, I'm writing a mochiweb app and hating life
>>  because I haven't found a good way to reduce the amount of noise
>>  created by the gargantuan case statement created by splitting up the
>>  url.
>
> I don't use mochiweb so I can't comment on that, but with yaws I use
> separate functions to handle each URI as described here:
>
> <http://www.infoq.com/articles/vinoski-erlang-rest>
>
> In my experience breaking the handlers into different functions makes
> them more convenient to deal with. I'd be very surprised if you
> couldn't do something similar with mochiweb.
>
> (An aside: Joe Armstrong and I were wondering back at Erlang eXchange
> in July: maybe this is a dumb question but how do you actually
> pronounce "mochiweb" -- is it "mo-chee-web" or "mo-key-web" or
> "mock-key-web" or ...?)
>
>>  When writing web applications like this in python, there are
>>  often some nice tools provided to at least make the matching list of
>>  routes more readable (see, routes, django urls, werkzeug etc.). Many
>>  of these actually use regexes or a matching techniques that I could
>>  also use in erlang, it just feels like a shame that matches aren't
>>  more readily available as first class citizens.
>
> If you own the URIs, then you can make them as friendly as you want
> for the function arg matching approach described above. Some people
> downplay the design of URIs as being relatively unimportant, and from
> a client POV they're correct because a RESTful server is responsible
> for supplying the client with URIs embedded within hypermedia
> responses to drive the client through its application state, which
> means the client doesn't really need to care about the "shape" of the
> URIs. But from a server perspective, I disagree that URI design is
> unimportant -- if you design your URIs well, it definitely eases the
> difficulties of tying them to their underlying resource
> implementations.
>
> If you don't own the URIs, then matching can be a lot more problematic
> if the URIs are poorly designed. For example if they all use the same
> path and rely on query strings with lots of parameters for
> differentiation, then you're best off isolating their parsing into a
> function that effectively rewrites the URIs into something more
> friendly, and then dispatching them on that basis.
>
> I personally haven't seen any cases where I needed regexp URI matching
> for my RESTful web service implementations, but I acknowledge your
> mileage may vary.

Oh absolutely. The pattern isn't bad at all I do something very
similar in mochiweb (MOE-CHEE-WEB)

loop(Req) ->
    Resp = case string:tokens(Req:get(path), "/") of
        [] -> % GET
            roto_web_views:version(Req);

        ["version"] -> % GET
            roto_web_views:version(Req);

        ["register"] -> % POST
            roto_web_views:register(Req);

        ["nodes"] -> % GET
            roto_web_views:get_nodes(Req);

        ["nodes", NodeName] -> % GET DELETE
            roto_web_views:nodes(Req, NodeName);

        ["nodes", NodeName, "queues"] -> % GET POST
            roto_web_views:queues(Req, NodeName);

        ["nodes", NodeName, "messages"] -> % GET POST
            roto_web_views:messages(Req, NodeName);
        _ ->
            {404, [], "{'error': 404, 'msg': \"Path not found\""}
    end,

    Req:respond(Resp),
    ok.

That being said I would love to be able to do

URLS = [{module, roto_web_view}
        {[],                                version},
        {["version"],                       version},
        {["register"],                      register},
        {["nodes"],                         get_nodes},
        {["nodes", NodeName],               nodes};
        {["nodes", NodeName, "queues"],     queues};
        {["nodes", NodeName, "messages"],   messages};
        ],

where each function get's passed the Request and any matches in the
order they were specified.

~ Anders



>
> --steve
>