On 11/11/2014 08:02 AM, Richard Jones wrote:
Hi all,
At the summit last week, we developed a plan for moving forward with
modernising Horizon's UI using AngularJS. If you weren't at that
meeting and are interested in helping out with this effort please let
me know!
The relevant etherpad from the meeting:
https://etherpad.openstack.org/p/kilo-horizon-contributors-meetup
TL;DR: piece by piece we will replace Django views in Horizon with
angular views, and we're going to start with Identity
First up, I'd like to ask the UX folk who raised their hands in that
meeting to indicate which of the Identity panes we should start with.
I believe a wizard was mentioned, as a way to exercise the new wizard
code from Maxime.
At the same time, I'm looking at updating the AngularJS
recommendations in the wiki. I believe other aspects of the current
approach to angular code should also be revisited, if we're to scale
up to the full angular front-end envisaged. I'd appreciate if those
interested in this aspect in particular could contact me so we can
sort this out as a team!
I'd like to start the design work for the new REST API layer we'll be
exposing to the angular application code, but that is also part of the
broader discussion about the structure of the angular code in the
Horizon application as mentioned above. Should it be a new blueprint/spec?
There were some discussions around tooling. We're using xstatic to
manage 3rd party components, but there's a lot missing from that
environment. I hesitate to add supporting xstatic components on to the
already large pile of work we have to do, so would recommend we switch
to managing those components with bower instead. For reference the
list of 3rd party components I used in angboard* (which is really only
a teensy fraction of the total application we'd end up with, so this
components list is probably reduced):
json3
es5-shim
angular
angular-route
angular-cookies
angular-animate
angular-sanitize
angular-smart-table
angular-local-storage
angular-bootstrap
angular-translate
font-awesome
boot
underscore
ng-websocket
Just looking at PyPI, it looks like only a few of those are in
xstatic, and those are out of date.
grunt provides a lot of features for developing an angular interface.
In particular LiveReload accelerates development significantly.
There's a django-livereload but it uses tiny-lr under the hood, so
we're still using a node application for LiveReload support... so it
might make sense to just use grunt. grunt provides many other features
as well (wiredep integration with bower, build facilities with ngMin,
test monitoring and reload etc).
There seemed to be agreement to move to jasmine (from qunit) for
writing the tests. It's not noted in the etherpad, but I recall karma
was accepted as a given for the test runner. For those not in the
meeting, angboard uses mocha+chai for test writing, but I agreed that
jasmine is acceptable, and is already used by Storyboard (see below).
Also, phantomjs so we don't have to fire up a browser for exercising
(what should hopefully be an extensive) unit test suite.
The Storyboard project has successfully integrated these tools into
the OpenStack CI environment.
Richard
* https://github.com/r1chardj0n3s/angboard
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I am going to try to conclude what has been said in emails across this
thread.
As Monty Taylor said, nodejs itself is not a blocker as multiple
versions of it should not be needed by our tools. (That's also what npm
and bower are taking care of, right?) Only thing that is required is
that all tools/js libs we want to use would eventually have to be
packaged. This is just a bunch of work for packagers.
Approach on using Xstatic packages vs Js tooling:
As only problem with using js tooling should be just actual packaging of
it, I think it makes sense to use these tools and make development
simpler then going other way around and using Xstatic packages - which
means devs would have to care about getting stuff packaged as xstatic
and added to the code, while maintaining proper versions and making sure
that they work ok together. NPM and Bower do this for us. Common sense
tells me packagers should take care of packaging.
Packaging of these tools will have to get resolved somehow anyway, as
there will be rise in requirements of using them not just from Horizon...
Which tools should we use eventually:
Based on the contributions by Maxime, Martin and the others, I think the
list of tools should end up as follows:
Tooling:
npm
bower
gulp
Jasmine
Karma/Protractor(?)/eslint
...?
Bower and Gulp seems to get along well
(https://github.com/yeoman/generator-gulp-webapp)
Tastypie on the Django side
Angular modules - probably as listed in Richard's initial email + some more:
angular-ui
...
I might be wrong with my assumptions, so please feel free to disagree.
Jiri
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev