Open Stack

On 11 November 2014 20:53, Jiri Tomasek <jtomasek at redhat.com> wrote:

>  Hey,
>
> Thanks for writing this up!
>
> I am including some notes and questions inline...
>
> 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 am interested.
>

Excellent!



> 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?
>
>
> I think spec seems appropriate.  Do you think using django-angular would
> be convenient?
>

As I understand it, django-angular exists to make it easier to integrate
Django views and angular views, whereas what we're after is for them to be
as separate as possible, with Django providing a single templated page that
forms the base page for the angular single-page app, and the REST API is as
un-Django as possible (using something like tastypie).




> 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.
>
>
> Using javascript tooling (yeoman, grunt, bower, etc.) has this issue of
> being dependent on nodejs which if I recall correctly is causing problems
> for packagers as some versions of these tools require different nodejs
> versions - please Mathias correct me if I am wrong. I know this discussion
> has been here before, but using these tools is necessary for effective
> development. So we need to resolve the problem asap. Storyboard does not
> have this issue as it is infra thing.
>

Infra still did have to do work to make things reliably build, and part of
their solution was to install a pinned version of node.js using nodeenv -
that is, node is installed into and alongside the virtualenv just like
Python packages are. Using a pinned version removes the version
compatibility issue, and using nodeenv means there's no impact to the
broader system like you'd get with a standard node install.



Petr Belanyi has added optional jshint install for js linting into Horizon
> and it installs nodejs as it depends on it. Could this approach work for
> our need of js tooling too? [1]
>

Ah, this also uses nodeenv. Yes, this is what we'd be looking at doing also.



How hard is it going to be if we'll need to go xstatic way? Is that even
> possible?
>

It's quite possible, but someone or some people would have to dedicate time
to keeping xstatic packages up to date.



     Richard
>
>  * https://github.com/r1chardj0n3s/angboard
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> [1] https://review.openstack.org/#/c/97237/
>
>
> Jiri
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141111/01ecdeff/attachment.html>