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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
