6192bfd7ac
This patch demonstrates how promises returned by actions are used by the images table. In particular, notice how specific action event handlers do not need to be registered. This allows a view to support a wide variety of actions without needing to setup a specific event listener for each type of event the action might emit. One could argue that if action events were standardized, they could still be used, which is true. Consider a generic SUCCESS event. However, promises have additional benefits and avoid some of the problems of events. One advantage is that promises make it easy to "chain" multiple handlers to a single success or failure. For example, once ALL of these actions have completed successfully, then update a status icon. We see another example of this in the delete-action.service which uses a promise chain to convert the data returned by the delete-modal.service into a standardized form used by actions. Also, promises don't require that the caller have a parent scope. In angular, events "bubble" from child scope to the parent scope. These scopes are effectively the view hierarchy, where a panel contains a table, which contains rows, which contain buttons. However, actions are not view elements lke a table or input box. Actions, like "delete image" are a behavior that may be invoked independently, and the code that cares about the success or failure of that action may not be a scope parent. Added an action-result service that provides a convenience object for creating such results. Co-Authored-By: Matt Borland <matt.borland@hpe.com> Partially-Implements: blueprint angular-registry Change-Id: Id6725664e5654a4f75508993b9640a0de80c6884 |
||
|---|---|---|
| doc | ||
| horizon | ||
| openstack_dashboard | ||
| releasenotes | ||
| tools | ||
| .eslintignore | ||
| .eslintrc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .pylintrc | ||
| .testr.conf | ||
| babel-django.cfg | ||
| babel-djangojs.cfg | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| Makefile | ||
| manage.py | ||
| MANIFEST.in | ||
| package.json | ||
| README.rst | ||
| requirements.txt | ||
| run_tests.sh | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| test-shim.js | ||
| tox.ini | ||
Horizon (OpenStack Dashboard)
Horizon is a Django-based project aimed at providing a complete
OpenStack Dashboard along with an extensible framework for building new
dashboards from reusable components. The
openstack_dashboard module is a reference implementation of
a Django site that uses the horizon app to provide
web-based interactions with the various OpenStack projects.
- Release management: https://launchpad.net/horizon
- Blueprints and feature specifications: https://blueprints.launchpad.net/horizon
- Issue tracking: https://bugs.launchpad.net/horizon
Using Horizon
See doc/source/topics/install.rst about how to install
Horizon in your OpenStack setup. It describes the example steps and has
pointers for more detailed settings and configurations.
It is also available at http://docs.openstack.org/developer/horizon/topics/install.html.
Getting Started for Developers
doc/source/quickstart.rst or http://docs.openstack.org/developer/horizon/quickstart.html
describes how to setup Horizon development environment and start
development.
Building Contributor Documentation
This documentation is written by contributors, for contributors.
The source is maintained in the doc/source directory
using reStructuredText and
built by Sphinx
Building Automatically:
$ ./run_tests.sh --docsBuilding Manually:
$ tools/with_venv.sh sphinx-build doc/source doc/build/html
Results are in the doc/build/html directory