Improve breadcrumbs about angular-app

[petebacondarwin]

Yes, we talked about maybe extracting the breadcrumbs from the routing
system?

On 23 September 2012 18:49, Pawel Kozlowski [email protected]:

Currently we are showing Mongo ids in the breadcrumbs, this doesn't look.
It is an interesting conceptual problem as well linked to the routing
system.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/24.

[petebacondarwin]

Definitely need a more powerful routing system in Angular in the long run.

On 23 September 2012 20:09, Peter Bacon Darwin [email protected] wrote:

Yes, we talked about maybe extracting the breadcrumbs from the routing
system?

On 23 September 2012 18:49, Pawel Kozlowski [email protected]:

Currently we are showing Mongo ids in the breadcrumbs, this doesn't look.
It is an interesting conceptual problem as well linked to the routing
system.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/24.

[pkozlowski-opensource]

Yes, the current routing system and form's validation are probably the
2 weakest points of AngularJS atm...

[pkozlowski-opensource]

OK, so as far as breadcrumbs are concerned, we should be extracting them from the routing system somehow. It should be possible since, after a route is resolved, we've got access to all the route params and resolved locals. I can see 2 solutions:

• equip our resource classes with a well-known function (toString ?) and use result of this function in a breadcrumb
• define a function on a route definition level that would indicate which properties of a resource object to take as a breadcrumb

[pkozlowski-opensource]

We need to cross-check a link in a breadcrumb against a set of defined routes (to avoid the situation where a link leads to a route that is not defined and as a result fallback to a default one).

[pkozlowski-opensource]

Thinking about it a bit more it becomes even more clear that breadcrumbs must be more linked to the routing system and not to the loacation's path. This becomes very evident when we see how routing system works with promises (resolve). As of today a route won't change if one of the promises fail but the $location will be updated anyway. As a result the breadcrumbs will get updated as if a user navigated to a target route while in fact no navigation taken place.

In short: the breadcrumbs should be extracted from the current route and links in a bradcrumbs cross-checked with defined routes.

[petebacondarwin]

We ought to find a way to revert the location too if it fails.

... sent from my tablet
On 6 Oct 2012 10:49, "Pawel Kozlowski" [email protected] wrote:

Thinking about it a bit more it becomes even more clear that breadcrumbs
must be more linked to the routing system and not to the loacation's path.
This becomes very evident when we see how routing system works with
promises (resolve). As of today a route won't change if one of the
promises fail but the $location will be updated anyway. As a result the
breadcrumbs will get updated as if a user navigated to a target route while
in fact no navigation taken place.

In short: the breadcrumbs should be extracted from the current route and
links in a bradcrumbs cross-checked with defined routes.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-9196840.

[pkozlowski-opensource]

OK, so after merging b157f17 we still got 3 (at least) improvements to be done:

• display a link in a breadcrumb only if a corresponding route exists
• display human-readable info in breadcrumbs instead of ids (somehow we need to attach a piece of code to a route)
• revert a location if a route change fails