Am 12.09.2012 21:36, schrieb Eldar Insafutdinov:
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
seems like a nice naming alternative.
Yeah, I already noticed that that there is addRoute, so I'll rename it.
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
I've thought about the state machine approach and it should actually mix
fine with arbitrary delegates, just that those are of coursed scanned
The basic idea is that there is a decision graph where each node node
matches a single character or a range of characters. 'Children'
represent matches for the next character and any node contains a list of
matching routes. The input URL is then piped through the graph and every
matching route on the way is marked. At the end, the marked routes are
executed in sequence. Routes with arbitrary callbacks would just always
be executed in the last step in addition to the marked routes.
Maybe there will also need to be some additional node annotations for
capturing the wildcard/:variable contents but basically this is how it
All in all, since they don't really contradict the state machine
approach, arbitrary match delegates should be fine actually. Regexes
could also be inserted into the state machine graph, but that's
something I would rather not want to do because of it's complexity. So
unless someone is adventurous, they would probably just be implemented
as match delegates.
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?
A possible pattern for pluggable modules is that the module registers
itself in a passed in UrlRouter (e.g. vibelog is doing this). If you
then have a few of these modules, it's easy to get to those numbers. Of
course it is also possible to nest multiple routers to get closer from
O(n) to O(log(n)):