On 13/11/13 11:47 +0100, Jiri Tomasek wrote:
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.
I agree that a command line utility seems like the most sensible "non-js" implementation of Horizon features. Additionally, we can write javascript with AngularJS that is friendly to various accessibility needs, like screen readers. I mentioned this in the chat last night and promised some examples. Here's an excellent walkthrough of using ARIA tags with javascript:http://stackoverflow.com/questions/15318661/accessibility-in-single-page-applications-aria-etc
And a little more: http://webaim.org/techniques/javascript/eventhandlers http://stackoverflow.com/questions/18853183/what-are-the-accessibility-implications-of-using-a-framework-like-angularjs Basically, if you can make an HTML page friendly to screen readers, you can make a javascript-built app friendly to screen readers.
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.
In my experience, the performance has always been "Excellent", but there could certainly be use cases where it's not Thanks! -- Jordan O'Mara <jomara at redhat.com>Red Hat Engineering, Raleigh
pgpt0gsCbrkvn.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
