RejectedSoftware Forums

On Wednesday, 12 September 2012 at 17:01:19 UTC, Sönke Ludwig
wrote:

Am 12.09.2012 16:10, schrieb Eldar Insafutdinov:

Hi all!

I've been thinking about routing lately and I think that the
system can
be made more generic. There can be various way of matching an
URL like
the current way, regexps etc. We should start by providing the
very
basic functionality - API that expects a predicate:

enum HTTP {
    GET,
    POST,
    UPDATE,
    DELETE
}

class Router {
    ...
    Router match(HTTP reqType, bool delegate(string) 

predicate,
HttpRequestHandler);

}
auto router = new Router;
router.match(HTTP.GET, (url) => url == "/", &handleIndex);

Having the most generic API we can provide a more specific
implementations like the current or regex:

class Router {
    ...
    Router match(HTTP reqType, string pattern, 

HttpRequestHandler);

Router match(HTTP reqType, Regex!char pattern, 

HttpRequestHandler);

}

Also, using enumeration for request type rather than dedicated
methods
get(), post() etc is more flexible. Does it look good and does
anyone
have any other thoughts? If yes, I will then go ahead with it
and submit
a pull request.

I was thinking about implementing a state machine based
matching of
routes at some point to improve performance with many routes.
That would
collide a bit with opaque callbacks. But maybe the performance
will be
sufficient for almost any application anyway... I think it
would be good
to make a quick benchmark to see how the number of routes
affects the
total request time before committing to this approach.

How many paths are you thinking here? tens or hundreds?

Btw. router.match() is the same as router.addRoute() is now,
but 'match'
seems like a nice naming alternative.

Yeah, I already noticed that that there is addRoute, so I'll
rename it.

On Wednesday, 12 September 2012 at 19:10:50 UTC, Sönke Ludwig
wrote:

Am 12.09.2012 20:20, schrieb Eldar Insafutdinov:

How many paths are you thinking here? tens or hundreds?

I would say something in the range of one hundred is realistic
for a
moderately complex web app (I have one half finished with about
50
routes). So if say 200 are not affecting performance, the state
machine
approach is probably not needed.

Btw. router.match() is the same as router.addRoute() is now,
but 'match'
seems like a nice naming alternative.

Yeah, I already noticed that that there is addRoute, so I'll
rename it.

Ok

I don't quite understand about how exactly to use state machines
here, but I just thought - if there were support for Regexps how
would that fit in?

Also as for 100-200 routs - is that realistic to use together
with the Router class? Because to me if you have this many routs,
you might as well write your own handler that implements
IHttpServerRequestHandler interface and does some custom logic?

On Wednesday, 12 September 2012 at 19:50:22 UTC, Nick Sabalausky
wrote:

On Wed, 12 Sep 2012 21:36:52 +0200
"Eldar Insafutdinov" e.insafutdinov@gmail.com wrote:

I don't quite understand about how exactly to use state
machines here, but I just thought - if there were support for
Regexps how would that fit in?

AIUI:

It would essentially be a lexer.

Vibe.d would collect all the regexes. Then, instead of the
usual regex
approach of building one NFA/DFA for each regex (with one
"Accept"
state each), it would essentially combine them like this:

(regex1)|(regex2)|(regex3)|(etc.)

And each of those parts would have their own separate
"accept" state.

Ie, a lexer.

The main issue that got me started on this thing is that
currently wild-cards are not captured, so something like this
wouldn't work:

 router.get("/assets/*", serveStaticFiles("./public/"));

Currently when the matcher sees wildcard and it just returns a
match. That brings us to the question - do we really want to
support them properly? Sinatra has the following:

 get '/say/*/to/*' do
   # matches /say/hello/to/world
   params[:splat] # => ["hello", "world"]

To do that the parser has to be a lot more sofisticated than it
currently is. The easiest option would be of course just to match
and capture the first * and be done with it.

Am 12.09.2012 22:25, schrieb Eldar Insafutdinov:

On Wednesday, 12 September 2012 at 19:50:22 UTC, Nick Sabalausky wrote:

On Wed, 12 Sep 2012 21:36:52 +0200
"Eldar Insafutdinov" e.insafutdinov@gmail.com wrote:

I don't quite understand about how exactly to use state machines
here, but I just thought - if there were support for Regexps how
would that fit in?

AIUI:

It would essentially be a lexer.

Vibe.d would collect all the regexes. Then, instead of the usual regex
approach of building one NFA/DFA for each regex (with one "Accept"
state each), it would essentially combine them like this:

(regex1)|(regex2)|(regex3)|(etc.)

And each of those parts would have their own separate "accept" state.

Ie, a lexer.

The main issue that got me started on this thing is that currently
wild-cards are not captured, so something like this wouldn't work:

router.get("/assets/*", serveStaticFiles("./public/"));

(I know you figured this out already... just posting here to remember
adding it to the docs later)

The following ought to work:

auto settings = new HttpFileServerSettings;
settings.serverPathPrefix = "/assets/";
router.get("/assets/*", serveStaticFiles("./public/", settings));

Currently when the matcher sees wildcard and it just returns a match.
That brings us to the question - do we really want to support them
properly? Sinatra has the following:

get '/say/*/to/*' do
  # matches /say/hello/to/world
  params[:splat] # => ["hello", "world"]

To do that the parser has to be a lot more sofisticated than it
currently is. The easiest option would be of course just to match and
capture the first * and be done with it.

Personally, all I've ever needed was '*' at the end for matching routes
for serveStaticFiles() and :var-style routes for anything else. That's
obviously also a reason why the wildcard support was never improved
beyond that.

But even if it stays at its current limited functionality, I would
improve two things: throw an error if a route has a '' that is not at
the end of the string, and put the contents matched by the '' into
something like params["wildcard"].