Rename parseRoute function

[mpscholten]

[CSchank]

Perhaps generateRoute or generateRoutes?

[s0kil]

I was thinking simply route, route @SessionsController

[CSchank]

Are we going to leave parseRoute for now to avoid breaking people's old code? I can see arguments for both sides.

[mpscholten]

We can rename it and add an alias e.g. parseRoute = route :) Then it will not break code but all new projects have a nicer function name :)

[zacwood9]

While we're on the topic of naming routing functions, I think the most misleading is the controllers method for FrontController. That implies it is a list of "controllers" of some sort when in reality it's a list of Parser (IO ResponseReceived).

In fact the whole routing system is based on this. parseRoute makes a bit more sense in context:

• parseRoute takes an instance of CanRoute which has the method parseRoute'.
• parseRoute' is an Attoparsec parser which parses the controller type from a given request, or fails.
• Using parseRoute', parseRoute runs the parser and calls action on the result which returns a IO ResponseReceived

So each "Application" routes by having a list of parsers which are run until one passes. These lists are combined in the RootApplication FrontController instance through mountFrontController.

I think the naming of these functions should reflect better that a list of Parsers are being created. Maybe controllers could be named routeParsers and parseRoute could be named createRouteParser? It's not as magical as route but I think it better conveys how the system actually works. I know for me the names made things confusing as I was trying to learn how AutoRoute works.

(p.s. this makes routing every request linear in the size of controller actions, which I would imagine could be a bottleneck as an app grows. No profiling data to support this, but it might be worth profiling and perhaps changing to some hash based solution eventually)

[mpscholten]

we cannot easily build a list like [ShowUserAction, ShowProjectAction] as this list would have a type UsersController | ProjectsController which cannot be represented in haskell. That's why the existing functionality is returning Parser (IO ResponseReceived). As this is more of a implementation detail (could change in the future if we find a better design), I'd be happy to rename the function. The current name only makes sense if you understand the implementation details :)

this makes routing every request linear in the size of controller actions, which I would imagine could be a bottleneck as an app grows. No profiling data to support this, might be worth doing that and perhaps changing to some hash based solution eventually

yes 👍

[CSchank]

I honestly feel like the number of people who would need to understand the fact that implementation detail is very small anyway imo.