<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 November 2014 20:53, Jiri Tomasek <span dir="ltr"><<a href="mailto:jtomasek@redhat.com" target="_blank">jtomasek@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Hey,<br>
      <br>
      Thanks for writing this up!<br>
      <br>
      I am including some notes and questions inline...<span class=""><br>
      <br>
      On 11/11/2014 08:02 AM, Richard Jones wrote:<br>
    </span></div><span class="">
    <blockquote 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 href="https://etherpad.openstack.org/p/kilo-horizon-contributors-meetup" target="_blank">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>
    </blockquote></span>
    I am interested.</div></blockquote><div><br></div><div>Excellent!</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr"><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?<br></div>
      </div>
    </blockquote>
    <br></span>
    I think spec seems appropriate.  Do you think using django-angular
    would be convenient?</div></blockquote><div><br></div><div>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).</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr"><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):<br></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>
    </blockquote>
    <br></span>
    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.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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]<br></div></blockquote><div><br></div><div>Ah, this also uses nodeenv. Yes, this is what we'd be looking at doing also.</div><div><br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">How hard is it going to be if we'll need to go xstatic way? Is that
    even possible?</div></blockquote><div><br></div><div>It's quite possible, but someone or some people would have to dedicate time to keeping xstatic packages up to date.</div><div><br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr"><div>     Richard</div>
        <div><br>
        </div>
        <div>* <a href="https://github.com/r1chardj0n3s/angboard" target="_blank">https://github.com/r1chardj0n3s/angboard</a><br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br></span>
    [1] <a href="https://review.openstack.org/#/c/97237/" target="_blank">https://review.openstack.org/#/c/97237/</a><span class="HOEnZb"><font color="#888888"><br>
    <br>
    <br>
    Jiri<br>
  </font></span></div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>