[openstack-dev] [Horizon] the future of angularjs development in Horizon
zigo at debian.org
Wed Nov 12 11:34:27 UTC 2014
On 11/11/2014 03:02 PM, 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:
> 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):
Let's please continue to use xstatic packages, which are very good for
distributions. I will do the effort on the Debian side of things to make
sure that we have all packaged correctly. Using some "magic" that do the
same kind of horrible stuff as "pip install" or "pear install" or CPAN,
or... you name it, will not fix things on my side. Quite the opposite,
it will add issues after issues. The XStatic things, on the other hand,
is very easy for me to maintain, even though that's a lot of work.
On 11/12/2014 04:03 PM, Matthias Runge wrote:
> There are companies out there, where security policy does not allow to
> install software from a third party repository. pypi etc. are
> considered as a third party here in this context.
It's also not Debian policy compliant to download from these sources in
a package. So that'd be a no-go for Debian, and anyway, these
dependencies would have to be packaged in some way.
Again, let's please stick on the xstatic way of doing things. It worked
for Juno, let's make it work for Kilo as well.
Thomas Goirand (zigo)
More information about the OpenStack-dev