I like the idea of route-matching plugability. I'm just no big fan of encapsulating this as a function - would much rather prefer a dedicated service for this so people can create AngularJS modules with an alternative implementation. This should make unit-testing easier as well.

I'm not attached to any particular implementation. The key thing for me is
that there is a straightforward way to implement alternative routing logic.

Are you able to outline how this would work as a service. I'm still getting
my head around how angular is plumbed together. How would the routeProvider
know about the alternative route matcher, would the service be passed in
like the callback function with my implementation, or is there another way
this would be done?

On 6 May 2013 06:23, Pawel Kozlowski notifications@github.com wrote:

I like the idea of route-matching plugability. I'm just no big fan of
encapsulating this as a function - would much rather prefer a dedicated
service for this so people can create AngularJS modules with an alternative
implementation. This should make unit-testing easier as well.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2571#issuecomment-17456219
.

Very interested in this. For what I had in mind, I'd be able to generate a JSON of all resourceful routes of my API server, and use it in a custom angular router to auto generate equivalent factories for resources.

-1
There really isn't very much to the $route service other than the route matcher and a bit of waiting for resolves to complete. If you wanted to have a different implementation then it is quite easy to write your own $route service from scratch and give it the name $route, so that it overwrites the built in one. ng-view will then use this service when it starts up.$routeParams is completely $route agnostic anyway.

This is the D.I. way.

In fact if you refactored ng-view to use the next and last route variables that get passed through with the $routeChangeSuccess event, rather than relying on the $route.current property, then ng-view would be $route agnostic and you could simply plug in your own router, without even overwriting the built in one. It would simply need to use $routeParams and fire the appropriate events.

Overriding $route entirely could work, but this approach needs to be documented, so there is a clear path for people who need alternative routing logic. This is not at all obvious to people who do not have a thorough understanding of DI works. Who knew you could overide a service.

However, there appears to be a bit more in there than switchRouteMatcher (40 lines of code). updateRoute (70 lines of code) seems to encapsulate the details of how the route service interacts with the rest of angular. It would be convinient not to have to reinvent, or copy and paste, this. Maybe this code could be moved elsewhere. Understanding all the details of how the router interacts with the rest of angular is a large barrier.

To put things in perspective, I've done this so I can use one viewcontroller if an arguments is an integer, and another if the argument is a string.

The key problem is that the current router is not flexible enough for all use cases and there is no clear way to overcome this except by maintaining a local fork of angular.

I don't really follow you on the refactoring of ng-view.

It is worth noting, for my case at least, that the current route provider handles 99% of the routing cases. All I am after is a simple way to get a bit more control over routing decisions. Having learn't what I've learnt from writing this patch, what I would instead do is modify the router so the route given to $routeProvider.when() could be a function, which would be called to process the route args and return the route.

This of course does not give as much flexibilty as being able to override the entire route matcher, which from reading other pull requests around routing, I gather would be desirable.

On 11/05/2013, at 1:47 AM, Pete Bacon Darwin notifications@github.com wrote:

-1
There really isn't very much to the $route service other than the route matcher and a bit of waiting for resolves to complete. If you wanted to have a different implementation then it is quite easy to write your own $route service from scratch and give it the name $route, so that it overwrites the built in one. ng-view will then use this service when it starts up.$routeParams is completely $route agnostic anyway.

This is the D.I. way.

In fact if you refactored ng-view to use the next and last route variables that get passed through with the $routeChangeSuccess event, rather than relying on the $route.current property, then ng-view would be $route agnostic and you could simply plug in your own router, without even overwriting the built in one. It would simply need to use $routeParams and fire the appropriate events.

—
Reply to this email directly or view it on GitHub.

Have you taken a look at ui-router: https://github.com/angular-ui/ui-router/wiki? It could provide you with an alternative?

I've got a better plan Hoggle. #2834