<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/11/2014 08:02 AM, Richard Jones
wrote:<br>
</div>
<blockquote
cite="mid:CAHrZfZDQxnPWUAnyYtJfUQNdQ5wPUQ=6_h7ek69N5eGodiU-sw@mail.gmail.com"
type="cite">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>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!</div>
<div><br>
</div>
<div>The relevant etherpad from the meeting:</div>
<div><a moz-do-not-send="true"
href="https://etherpad.openstack.org/p/kilo-horizon-contributors-meetup">https://etherpad.openstack.org/p/kilo-horizon-contributors-meetup</a><br>
</div>
<div><br>
</div>
<div>TL;DR: piece by piece we will replace Django views in
Horizon with angular views, and we're going to start with
Identity</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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!</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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):</div>
<div><br>
</div>
<div>
<div> json3</div>
<div> es5-shim</div>
<div> angular</div>
<div> angular-route</div>
<div> angular-cookies</div>
<div> angular-animate</div>
<div> angular-sanitize</div>
<div> angular-smart-table<br>
</div>
<div> angular-local-storage</div>
<div> angular-bootstrap</div>
<div> angular-translate</div>
<div> font-awesome</div>
<div> boot</div>
<div> underscore</div>
<div> ng-websocket</div>
<div><br>
</div>
</div>
<div>Just looking at PyPI, it looks like only a few of those are
in xstatic, and those are out of date.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>Also, phantomjs so we don't have to fire up a browser for
exercising (what should hopefully be an extensive) unit test
suite.</div>
<div><br>
</div>
<div>The Storyboard project has successfully integrated these
tools into the OpenStack CI environment.</div>
<div><br>
</div>
<div><br>
</div>
<div> Richard</div>
<div><br>
</div>
<div>* <a moz-do-not-send="true"
href="https://github.com/r1chardj0n3s/angboard">https://github.com/r1chardj0n3s/angboard</a><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<br>
I am going to try to conclude what has been said in emails across
this thread.<br>
<br>
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.<br>
<br>
<br>
Approach on using Xstatic packages vs Js tooling:<br>
<br>
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.<br>
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...<br>
<br>
<br>
Which tools should we use eventually:<br>
<br>
Based on the contributions by Maxime, Martin and the others, I think
the list of tools should end up as follows:<br>
<br>
Tooling:<br>
npm<br>
bower<br>
gulp<br>
Jasmine<br>
Karma/Protractor(?)/eslint<br>
...?<br>
<br>
Bower and Gulp seems to get along well
(<a class="moz-txt-link-freetext" href="https://github.com/yeoman/generator-gulp-webapp">https://github.com/yeoman/generator-gulp-webapp</a>)<br>
<br>
Tastypie on the Django side<br>
<br>
Angular modules - probably as listed in Richard's initial email +
some more:<br>
angular-ui<br>
...<br>
<br>
<br>
I might be wrong with my assumptions, so please feel free to
disagree.<br>
<br>
Jiri<br>
</body>
</html>