[openstack-dev] [Horizon] Routing in Horizon

Tripp, Travis S travis.tripp at hpe.com
Mon Jan 11 22:44:30 UTC 2016


Thanks for starting some discussion here.  I think your target=“_self” is taken care of now, right?

Re: ng-route vs ui-router - everything I have ever seen or been told supports using ui-router instead of ng-route.  I know a quick google search supports that, but let me google that for all of us and give several references:


So, I’m wondering if there’d been any discussion I missed on why not bring in ui-router?

Of course there is question using the new router in angular vs ui-router, but finding many pros- cons- on that seems to be a bit more difficult. Since it is 1.5 / 2.0 and neither are past rc / beta, it doesn’t seem like something we can debate too well.



From: Rajat Vig <rajatv at thoughtworks.com<mailto:rajatv at thoughtworks.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, January 7, 2016 at 1:53 AM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [Horizon] Routing in Horizon

Hi Everyone

One of my recent patches which enabled HTML5 based routing via Angular merged, some interesting things spun out.
I'd to scramble a few patches to get things
​​ back the same way
for all new Angular Panels.

I also realized that getting Horizon to an SPA with Angular requires more thought than mere fixing the current burning issue.
This mail's intent is to spur a direction on how we do routing in Angular and how do Angular Panels go back/forth between themselves and older Django panels.

The patch https://review.openstack.org/#/c/173885/ is possibly the first of many to use Angular based routing.
It currently uses ngRoute as the library was included in the xstatic-angular package.

What I'm roughly thinking to solve some of the immediate issues (there's possbily much more that I'm not)

1. If we are going to go with the SPA route, then all Panels need to indicate that they are Angular based.
For panels that are Angular, they need to declare routes they'd like to manage.

2. All tags on Angular Panels (including header, sidebar, footer) which don't route to Angular Panels will need the attribute target="_self" else Angular will not allow navigation to those links.

All sidebar links currently have the attribute set but headers and footers don't.
Sidebar links for Angular shouldn't have the attribute else SPA like behavior will not happen.
This will need to be documen

3. That implies yet another problem with the Spinner Modal which gets activated on all sidebar clicks.
It'll need to be done differently for Angular routing vs hrefs still with Django.
The current spinner relies on a browser page refresh to disappear.

Then there's ngRoute.
Routing needs in Angular may need to handle route conflicts and maybe nested routes.
There are other, possibly better options that we could consider
1. https://github.com/angular-ui/ui-router
2. https://angular.github.io/router/

I've been part of the community for not long enough yet and I'm not yet completely aware of what exists outside the Horizon codebase so I might be missing somethings as well.


More information about the OpenStack-dev mailing list