doc: cleanup formatting
* Clean up unnecessary vertical quotes at the left side caused by extra spaces at the beginning of lines. * Do not use backquotes in the title lines (ref/run_tests.rst, ref/horizon.rst) When backquotes are used in the first-level title, it will be included in the navigation at the top-right corner https://docs.openstack.org/developer/horizon/contributor/ref/index.html * Remove duplicated contents:: directive in ref/run_tests.sh. openstackdocstheme generates the toc by default, so having contents:: directive leads to duplicated toc in a page. Change-Id: Icc641927ad7cd7a8d79632c64a3ce212f0dc0b64
This commit is contained in:
Akihiro Motoki
parent
614bc7600a
commit
563908e2c0
@ -198,7 +198,8 @@ Required
|
||||
* Use ``===`` as opposed to ``==`` for equality checks. The ``==`` will do a
|
||||
type cast before comparing, which can lead to unwanted results.
|
||||
|
||||
.. Note ::
|
||||
.. note::
|
||||
|
||||
If typecasting is desired, explicit casting is preferred to keep the
|
||||
meaning of your code clear.
|
||||
|
||||
@ -282,13 +283,15 @@ Required
|
||||
|
||||
3. Avoid using classes for detection purposes only, instead, defer to
|
||||
attributes. For example to find a div:
|
||||
::
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<div class="something"></div>
|
||||
$(".something").html("Don't find me this way!");
|
||||
|
||||
Is better found like:
|
||||
::
|
||||
is better found like:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<div data-something></div>
|
||||
$("div[data-something]").html("You found me correctly!");
|
||||
|
||||
@ -113,11 +113,6 @@ on the best possible experience.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:ref:`quickstart`
|
||||
A short guide to getting started with using Horizon.
|
||||
|
||||
:ref:`faq`
|
||||
Common questions and answers.
|
||||
|
||||
:ref:`glossary`
|
||||
Common terms and their definitions.
|
||||
* :ref:`quickstart` A short guide to getting started with using Horizon.
|
||||
* :ref:`faq` Common questions and answers.
|
||||
* :ref:`glossary` Common terms and their definitions.
|
||||
|
||||
@ -88,11 +88,12 @@ That code would create the ``"switchable"`` control field ``source``, and the
|
||||
two ``"switched"`` fields ``cidr`` and ``security group`` which are hidden or
|
||||
shown depending on the value of ``source``.
|
||||
|
||||
.. note::
|
||||
|
||||
NOTE: A field can only safely define one slug in its ``"switch-on"`` attribute.
|
||||
A field can only safely define one slug in its ``"switch-on"`` attribute.
|
||||
While switching on multiple fields is possible, the behavior is very hard to
|
||||
predict due to the events being fired from the various switchable fields in
|
||||
order. You generally end up just having it hidden most of the time by accident,
|
||||
so it's not recommended. Instead just add a second field to the form and control
|
||||
the two independently, then merge their results in the form's clean or handle
|
||||
methods at the end.
|
||||
order. You generally end up just having it hidden most of the time by
|
||||
accident, so it's not recommended. Instead just add a second field to the
|
||||
form and control the two independently, then merge their results in the
|
||||
form's clean or handle methods at the end.
|
||||
|
||||
@ -41,5 +41,8 @@ Panel
|
||||
.. autoclass:: Panel
|
||||
:members:
|
||||
|
||||
Panel Group
|
||||
===========
|
||||
|
||||
.. autoclass:: PanelGroup
|
||||
:members:
|
||||
|
||||
@ -8,9 +8,6 @@ The run_tests.sh Script
|
||||
Queens (13.0), in favor of tox. The tox docs can be found at
|
||||
https://tox.readthedocs.io/en/latest/
|
||||
|
||||
.. contents:: Contents:
|
||||
:local:
|
||||
|
||||
Horizon ships with a script called ``run_tests.sh`` at the root of the
|
||||
repository. This script provides many crucial functions for the project,
|
||||
and also makes several otherwise complex tasks trivial for you as a
|
||||
@ -54,8 +51,7 @@ the following (steps for Fedora 18 minimal installation):
|
||||
``yum install firefox``.
|
||||
#. Connect to the VM by ``ssh -X``
|
||||
(if you run ``set|grep DISP``, you should see that the DISPLAY is set).
|
||||
#. Run
|
||||
``./run_tests.sh --with-selenium``.
|
||||
#. Run ``./run_tests.sh --with-selenium``.
|
||||
|
||||
Running a subset of tests
|
||||
-------------------------
|
||||
|
||||
@ -5,6 +5,7 @@ JavaScript Testing
|
||||
==================
|
||||
|
||||
There are multiple components in our JavaScript testing framework:
|
||||
|
||||
* `Jasmine`_ is our testing framework, so this defines the syntax and file
|
||||
structure we use to test our JavaScript.
|
||||
* `Karma`_ is our test runner. Amongst other things, this lets us run the
|
||||
@ -66,6 +67,7 @@ Writing Tests
|
||||
=============
|
||||
|
||||
Jasmine uses suites and specs:
|
||||
|
||||
* Suites begin with a call to ``describe``, which takes two parameters; a
|
||||
string and a function. The string is a name or title for the spec suite,
|
||||
whilst the function is a block that implements the suite.
|
||||
@ -88,7 +90,8 @@ You can read more about the functionality in the
|
||||
|
||||
To manually add specs, add the following array and relevant file paths to your
|
||||
enabled file:
|
||||
::
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
ADD_JS_SPEC_FILES = [
|
||||
...
|
||||
@ -100,6 +103,7 @@ Examples
|
||||
========
|
||||
|
||||
.. Note::
|
||||
|
||||
The code below is just for example purposes, and may not be current in
|
||||
horizon. Ellipses (...) are used to represent code that has been
|
||||
removed for the sake of brevity.
|
||||
@ -108,7 +112,8 @@ Example 1 - A reusable component in the **horizon** directory
|
||||
-------------------------------------------------------------
|
||||
|
||||
File tree:
|
||||
::
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
horizon/static/framework/widgets/modal
|
||||
├── modal.controller.js
|
||||
@ -117,7 +122,8 @@ File tree:
|
||||
└── modal.spec.js
|
||||
|
||||
Lines added to ``horizon/test/jasmine/jasmine_tests.py``:
|
||||
::
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
class ServicesTests(test.JasmineTests):
|
||||
sources = [
|
||||
@ -135,7 +141,8 @@ Lines added to ``horizon/test/jasmine/jasmine_tests.py``:
|
||||
]
|
||||
|
||||
``modal.spec.js``:
|
||||
::
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
...
|
||||
|
||||
@ -204,7 +211,8 @@ Example 2 - Panel-specific code in the **openstack_dashboard** directory
|
||||
------------------------------------------------------------------------
|
||||
|
||||
File tree:
|
||||
::
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
openstack_dashboard/static/dashboard/launch-instance/network/
|
||||
├── network.help.html
|
||||
@ -215,7 +223,8 @@ File tree:
|
||||
|
||||
|
||||
Lines added to ``openstack_dashboard/enabled/_10_project.py``:
|
||||
::
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
LAUNCH_INST = 'dashboard/launch-instance/'
|
||||
|
||||
@ -232,7 +241,8 @@ Lines added to ``openstack_dashboard/enabled/_10_project.py``:
|
||||
]
|
||||
|
||||
``network.spec.js``:
|
||||
::
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
...
|
||||
|
||||
|
||||
@ -146,16 +146,16 @@ maintainers. Some of the most important ones are:
|
||||
- /usr is considered read only. Software must not write in /usr at
|
||||
runtime. However, it is fine for a package post-installation script to write
|
||||
in /usr. When this rule was not followed, distributions had to write many
|
||||
tricks to convince Horizon to write in /var/lib only. For example,
|
||||
distributions wrote symlinks to /var/lib/openstack-dashboard, or patched
|
||||
the default local_settings.py to write the SECRET_KEY in /var.
|
||||
tricks to convince Horizon to write in ``/var/lib`` only. For example,
|
||||
distributions wrote symlinks to ``/var/lib/openstack-dashboard``, or patched
|
||||
the default ``local_settings.py`` to write the ``SECRET_KEY`` in /var.
|
||||
- Configuration must always be in /etc, no matter what. When this rule
|
||||
was not followed, package maintainers had to place symlinks to
|
||||
/etc/openstack-dashboard/local_settings in Red Hat based distributions
|
||||
``/etc/openstack-dashboard/local_settings`` in Red Hat based distributions
|
||||
instead of using directly
|
||||
/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py
|
||||
``/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py``
|
||||
which Horizon expects. In Debian,the configuration file is named
|
||||
/etc/openstack-dashboard/local_settings.py.
|
||||
``/etc/openstack-dashboard/local_settings.py.``
|
||||
|
||||
|
||||
Packaging Horizon
|
||||
@ -203,11 +203,11 @@ Packaging Horizon for distributions
|
||||
|
||||
Horizon is a Python module. Preferably, it is installed at the default
|
||||
location for python. In Fedora and openSUSE, this is
|
||||
/usr/lib/python2.7/site-packages/horizon, and in Debian/Ubuntu it is
|
||||
/usr/lib/python2.7/dist-packages/horizon.
|
||||
``/usr/lib/python2.7/site-packages/horizon``, and in Debian/Ubuntu it is
|
||||
``/usr/lib/python2.7/dist-packages/horizon``.
|
||||
|
||||
Configuration files should reside under /etc/openstack-dashboard. Policy
|
||||
files should be created and modified there as well.
|
||||
Configuration files should reside under ``/etc/openstack-dashboard``.
|
||||
Policy files should be created and modified there as well.
|
||||
|
||||
It is expected that ``manage.py collectstatic`` will be run during package
|
||||
build.
|
||||
|
||||
@ -89,7 +89,7 @@ Cons:
|
||||
* Did I mention that setting it up is a pain?
|
||||
|
||||
Screenshot directory could be set through horizon.conf file, default value:
|
||||
"./integration_tests_screenshots"
|
||||
``./integration_tests_screenshots``
|
||||
|
||||
So what should I write?
|
||||
-----------------------
|
||||
|
||||
@ -592,6 +592,5 @@ What you've learned here is the fundamentals of how to write interfaces for
|
||||
your own project based on the components horizon provides.
|
||||
|
||||
If you have feedback on how this tutorial could be improved, please feel free
|
||||
to submit a bug against ``Horizon`` in `launchpad`_.
|
||||
|
||||
.. _launchpad: https://bugs.launchpad.net/horizon
|
||||
to submit a bug against ``Horizon`` in
|
||||
`launchpad <https://bugs.launchpad.net/horizon>`__.
|
||||
|
||||
@ -296,6 +296,5 @@ snapshot to other API calls that require more complex forms to gather the
|
||||
necessary information.
|
||||
|
||||
If you have feedback on how this tutorial could be improved, please feel free
|
||||
to submit a bug against ``Horizon`` in `launchpad`_.
|
||||
|
||||
.. _launchpad: https://bugs.launchpad.net/horizon
|
||||
to submit a bug against ``Horizon`` in
|
||||
`launchpad <https://bugs.launchpad.net/horizon>`__.
|
||||
|
||||
@ -241,14 +241,21 @@ class Column(html.HTMLElement):
|
||||
List of scope and rule tuples to do policy checks on, the
|
||||
composition of which is (scope, rule)
|
||||
|
||||
scope: service type managing the policy for action
|
||||
rule: string representing the action to be checked
|
||||
* scope: service type managing the policy for action
|
||||
* rule: string representing the action to be checked
|
||||
|
||||
for a policy that requires a single rule check,
|
||||
policy_rules should look like:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
for a policy that requires a single rule check:
|
||||
policy_rules should look like
|
||||
"(("compute", "compute:create_instance"),)"
|
||||
for a policy that requires multiple rule checks:
|
||||
rules should look like
|
||||
|
||||
for a policy that requires multiple rule checks,
|
||||
rules should look like:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
"(("identity", "identity:list_users"),
|
||||
("identity", "identity:list_roles"))"
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user