[erlang-questions] Pattern-matching function?

[Justin Sheehy]

On 10/30/08 12:27 PM, "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. 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.).

Have you tried Webmachine?

http://code.google.com/p/webmachine/

http://blog.therestfulway.com/2008/09/webmachine-is-resource-server-for-web.
html

It is a layer on top of mochiweb created to ease the building of
well-behaved Web applications, and includes a URL dispatcher written
by Robert Ahrens.  The dispatcher isn't exactly what you describe,
but is quite close and might serve your needs anyway as it has served
ours very well.

http://code.google.com/p/webmachine/wiki/DispatchConfiguration

On 10/30/08 3:28 PM, "Steve Vinoski" <vinoski@REDACTED> wrote:

> 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>

I like your use of the match-spec structure there, though we found
something only slightly different to work well for us in Webmachine.

> 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.

In my experience, if writing an app on pure mochiweb one tends to
start out writing everything in one big loop function and slowly
factor it out.  Part of the goal in Webmachine is to do much of
the right division of Web application code ahead of time, and also
to more easily capture correct HTTP behavior while doing so.

To that end we used the approach of resource definition modules,
Which are the first unit of this division and which are parameterized
and called as a result of the URL dispatch.

> how do you actually pronounce "mochiweb" -- is it "mo-chee-web" or
> "mo-key-web" or "mock-key-web" or ...?)

mo-chee-web

> 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.

I've had the same experiences.  I find regexes to be overkill here.

On 10/30/08 4:16 PM, "anders conbere" <aconbere@REDACTED> wrote:

> 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.

The following is a valid dispatch configuration in Webmachine:

URLS = [{[],                              roto_web_resource, [version]},
        {["version"],                     roto_web_resource, [version]},
        {["register"],                    roto_web_resource, [register]},
        {["nodes"],                       roto_node_resource, [nodes]},
        {["nodes", nodename],             roto_node_resource, [node]},
        {["nodes", nodename, "queues"],   roto_node_resource, [queues]},
        {["nodes", nodename, "messages"], roto_node_resource, [messages]}]

I could have made it more identical with yours, but I wanted to also point
out that there is some additional value to be had from the ease of breaking
things up into multiple resource definitions.  Here I made the arbitrary
choice that all of the URLs under /nodes would be handles by one resource,
and all others by a general resource -- the most sensible breakdown would of
course depend a great deal on the structure of your application.

Cheers,

-Justin