Open Stack

On 11/13/2013 11:20 AM, Maxime Vidori wrote:
> Hi all,
>
> I was wondering how can we continue to maintain a no js version of Horizon with the integration of Angular, it seems to be a lot of work on top of it.

I would favor not having to maintain the non-js functionality, as IMHO 
most of current modern UIs depend on javascript and the command line 
interface should take over where javascript is not available.
Though, if we want to maintain non-js functionality, directives are not 
a blocker. The directive html element can include the non-js code which 
is replaced by directive template when js and angular get's in.
If not, the original content of directive's element is available.

Maintaining non-js functionality becomes problematic when we need to 
serve multiple types of responses in controller - correct me if I am 
wrong, please.

> In addition, do we know the performance of Angularjs, where are the limits, it could be good to check some documentation and made some POC. I have tried the asynchronous API and I encountered some issues with the two way data bind.
> Does people have some feedbacks?

I didn't get any perfromance issues while using Angular, could you 
elaborate o the issues you had? I will try to search some performance 
related topics.

>
> Maxime Vidori
>
> ----- Original Message -----
> From: "Jiri Tomasek" <jtomasek at redhat.com>
> To: openstack-dev at lists.openstack.org
> Sent: Wednesday, November 13, 2013 11:00:43 AM
> Subject: Re: [openstack-dev] [Horizon] Introduction of AngularJS in membership workflow
>
> Hi,
>
> I'd like to point out, that our main intent should be to use mostly AngularJS's Directives feature.
> As Jordan mentions, It is a self-contained reusable item that is initialized on the html element
> (see line 6 in [2]), you can pass it variables that Django template has available. Then Angular takes
> over and replaces the html element with template that belongs to directive. The business logic
> is taken care by controller that is also assigned to the directive. The directive can get data either
> from the variables passed to the html element or better, through the service injected to controller.
> This service brings data asynchronously from our API.
>
> In our patch we are getting data using the current membership code, that brings data from
> hidden form. Maintaining the synchronization between the directive and the form involves quite
> a lot of code. Once we'd have the API on the Django side that would serve the data for membership
> component in json, the membership directive code would get reduced by a good amount.
>
> Reading back on yesterday's Horizon meeting, there was some confusion about "compile phase"
> The compile phase in angular does not have much to do with jasvascript compilation/minification.
> It is a phase in AngularJS when compiler parses the template and instantiates directives and expressions.
> ( http://www.benlesh.com/2013/08/angular-compile-how-it-works-how-to-use.html )
>
> Jirka
>
> On 11/11/2013 08:21 PM, Jordan OMara wrote:
>
>
> Hello Horizon!
>
> On November 11th, we submitted a patch to introduce AngularJS into
> Horizon [1]. We believe AngularJS adds a lot of value to Horizon.
>
> First, AngularJS allows us to write HTML templates for interactive
> elements instead of doing jQuery-based DOM manipulation. This allows
> the JavaScript layer to focus on business logic, provides easy to
> write JavaScript testing that focuses on the concern (e.g. business
> logic, template, DOM manipulation), and eases the on-boarding for new
> developers working with the JavaScript libraries.
> Second, AngularJS is not an all or nothing solution and integrates
> with the existing Django templates. For each feature that requires
> JavaScript, we can write a self-contained directive to handle the DOM,
> a template to define our view and a controller to contain the business
> logic. Then, we can add this directive to the existing template. To
> see an example in action look at _workflow_step_update_member.html
> [2]. It can also be done incrementally - this isn't an all-or-nothing
> approach with a massive front-end time investment, as the Angular
> components can be introduced over time.
>
> Finally, the initial work to bring AngularJS to Horizon provides a
> springboard to remove the "DOM Database" (i.e. hidden-divs) used on
> the membership page (and others). Instead of abusing the DOM, we can
> instead expose an API for membership data, add an AngularJS resource
> (i.e. reusable representation of API entities) for the API. The data
> can then be loaded data asynchronously and allow the HTML to focus on
> expressing a semantic representation of the data to the user.
> Please give our patch a try! You can find the interactions on
> Domains/Groups, Flavors/Access(this form does not seem to work in
> current master or on my patch) and Projects/Users&Groups. You should
> notice that it behaves...exactly the same!
> We look forward to your feedback. Jordan O'Mara & Jirka Tomasek
>
> [1] [ https://review.openstack.org/#/c/55901/ ] [2] [ https://github.com/jsomara/horizon/blob/angular2/horizon/templates/horizon/common/_workflow_step_update_members.html ]
>
>
> _______________________________________________
> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jirka