[CORD-2585]
Lint check documentation with markdownlint
Change-Id: I2b1d6a08b6784acd5a2ba884ea6cd535e7c8c137
diff --git a/docs/GLOSSARY.md b/docs/GLOSSARY.md
index ffadb1b..ff0e3e2 100644
--- a/docs/GLOSSARY.md
+++ b/docs/GLOSSARY.md
@@ -1,5 +1,11 @@
+# XOS-GUI Glossary
+
## SPA
-A single-page application (SPA) is a web application or web site that fits on a single web page with the goal of providing a user experience similar to that of a desktop application.
+
+A single-page application (SPA) is a web application or web site that fits on a
+single web page with the goal of providing a user experience similar to that of
+a desktop application.
## xProto
-That's a modeling language built on top of Google's Protocol Buffer.
\ No newline at end of file
+
+That's a modeling language built on top of Google's Protocol Buffer.
diff --git a/docs/README.md b/docs/README.md
index 1391e31..29a51c9 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -3,16 +3,18 @@
Welcome the User Manual for the XOS GUI, your visual interface to operate on XOS.
## Overview
-The XOS User Interfaced is developed as a single page application (from now on referred as SPA)
-and the main tools used are:
- - [Angular Js](https://angularjs.org/)
- - [Typescript](https://www.typescriptlang.org/)
- - [RxJS](http://reactivex.io/rxjs/)
-
+
+The XOS User Interface is developed as a single page application (from now on
+referred as SPA) and the main tools used are:
+
+* [Angular Js](https://angularjs.org/)
+* [Typescript](https://www.typescriptlang.org/)
+* [RxJS](http://reactivex.io/rxjs/)
+
## General information
-The XOS GUI is available trough the OpenCORD gerrit at: https://gerrit.opencord.org/#/admin/projects/xos-gui
+The XOS GUI is available trough the OpenCORD gerrit at:
+[https://gerrit.opencord.org/#/admin/projects/xos-gui](https://gerrit.opencord.org/#/admin/projects/xos-gui)
-> For instructions on how to get the code please refer to:
-> - https://wiki.opencord.org/display/CORD/Working+with+Gerrit
-> - https://wiki.opencord.org/display/CORD/Setting+up+and+using+REPO
+For instructions on how to get the code please refer to the [XOS Guide](https://guide.opencord.org/getting_the_code.html)
+
diff --git a/docs/SUMMARY.md b/docs/SUMMARY.md
index 83e18cb..9bd03f6 100644
--- a/docs/SUMMARY.md
+++ b/docs/SUMMARY.md
@@ -5,8 +5,8 @@
* [Architectural Overview](architecture/README.md)
* [Module Strucure](architecture/gui-modules.md)
* [Data Sources](architecture/data-sources.md)
-
+
* [Developer Guide](developer/README.md)
* [Quickstart](developer/quickstart.md)
* [Tests](developer/tests.md)
- * [GUI Extensions](developer/gui_extensions.md)
\ No newline at end of file
+ * [GUI Extensions](developer/gui_extensions.md)
diff --git a/docs/architecture/README.md b/docs/architecture/README.md
index 2ed1154..139887e 100644
--- a/docs/architecture/README.md
+++ b/docs/architecture/README.md
@@ -1,31 +1,45 @@
# Architectural Overview
-This chapter will guide you trough the general architecture of the XOS User Interfaces
+This chapter will guide you trough the general architecture of the XOS User
+Interfaces
## Ecosystem
-The XOS GUI is design to work in the XOS ecosystem, taking advantages of some of the features exposed by it.
-As an example the application is designed to discover the models registered in XOS
-and auto-generate CRUD views for all of them, feature that is available thanks to our xProto modeling language.
-We are also leveraging the XOS-WS component, build on top of our Redis based pub-sub system, to provide a progressive caching mechanism.
+The XOS GUI is design to work in the XOS ecosystem, taking advantages of some
+of the features exposed by it. As an example the application is designed to
+discover the models registered in XOS and auto-generate CRUD views for all of
+them, feature that is available thanks to our xProto modeling language. We are
+also leveraging the XOS-WS component, build on top of our Redis based pub-sub
+system, to provide a progressive caching mechanism.
-The GUI ecosystem in XOS is composed by a pod of 5 Docker containers that comunicate as per the following diagram:
+The GUI ecosystem in XOS is composed by a pod of 5 Docker containers that
+comunicate as per the following diagram:
-We'll talk deeper about the data flow in the [Developer Guide](../developer/README.md) but here is the main role of each component:
+We'll talk deeper about the data flow in the [Developer
+Guide](../developer/README.md) but here is the main role of each component:
-#### XOS-CORE
-Is hosting the entire data-model and expose a `gRPC` API layer to let other components interact with the data model.
+### XOS-CORE
-#### CHAMELEON
-Chameleon is reponsible to expose a description of the models stored in `XOS-CORE` and to provide the bindings between `REST` and `gRPC`
+Is hosting the entire data-model and expose a `gRPC` API layer to let other
+components interact with the data model.
-#### REDIS
+### CHAMELEON
+
+Chameleon is reponsible to expose a description of the models stored in
+`XOS-CORE` and to provide the bindings between `REST` and `gRPC`
+
+### REDIS
+
It is hosting a `redis` server used as primary pub-sub mechanism in the system
-#### XOS-WS
-Listen to `redis` events and transform them into `web-sockets` events in order to keep `XOS-GUI` updated
+### XOS-WS
-#### XOS-GUI
-Is hosting the GUI SPA and exposing it to the world through a web-server, in this case `nginx`
\ No newline at end of file
+Listen to `redis` events and transform them into `web-sockets` events in order
+to keep `XOS-GUI` updated
+
+### XOS-GUI
+
+Is hosting the GUI SPA and exposing it to the world through a web-server, in
+this case `nginx`
diff --git a/docs/architecture/data-sources.md b/docs/architecture/data-sources.md
index fe60491..a9f2877 100644
--- a/docs/architecture/data-sources.md
+++ b/docs/architecture/data-sources.md
@@ -1,19 +1,30 @@
# The Data Sources module and the observable pattern
-The Data Source module is the actual glue between the Single Page Application and XOS and is responsible to keep data up to date in the UI. It use a combination of REST APIs (used to fetch the initial data) and Websocket events (used to incrementally extend those data) and create a set of Observables.
+The Data Source module is the actual glue between the Single Page Application
+and XOS and is responsible to keep data up to date in the UI. It use a
+combination of REST APIs (used to fetch the initial data) and Websocket events
+(used to incrementally extend those data) and create a set of Observables.
-An observable is basically a sequence of ongoing events ordered in time, to know more about this topics you can start here: [The introduction to Reactive Programming you've been missing](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)
+An observable is basically a sequence of ongoing events ordered in time, to
+know more about this topics you can start here: [The introduction to Reactive
+Programming you've been
+missing](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)
The way synchronization is achieved follow this pattern:
-- When the application is loaded we read all the core model definition from the backend
-- For each Core Model
- - we read the existing data
- - we store them in an Observable
- - we generate a configuration for tables and forms
-- Any view that need those data require the Model Observable and the Model Configuration
-- For any Websocket event we trigger a new event in the related Observable
+
+* When the application is loaded we read all the core model definition from the
+ backend
+* For each Core Model
+ * we read the existing data
+ * we store them in an Observable
+ * we generate a configuration for tables and forms
+* Any view that need those data require the Model Observable and the Model
+ Configuration
+* For any Websocket event we trigger a new event in the related Observable
-You can see an example of this behavior in `/src/app/views/crud/crud.ts`.
-This view is responsible to auto-generate a CRUD interface for each model in the system.
\ No newline at end of file
+You can see an example of this behavior in `/src/app/views/crud/crud.ts`. This
+view is responsible to auto-generate a CRUD interface for each model in the
+system.
+
diff --git a/docs/architecture/gui-modules.md b/docs/architecture/gui-modules.md
index badb066..a011f1f 100644
--- a/docs/architecture/gui-modules.md
+++ b/docs/architecture/gui-modules.md
@@ -1,7 +1,7 @@
# GUI Modules
-The application is divided into Modules, each one responsible for a different topic, here is a short list of the modules and their area of focus:
-
+The application is divided into Modules, each one responsible for a different
+topic, here is a short list of the modules and their area of focus:
| Module | Topic |
|--------|-------|
@@ -10,4 +10,5 @@
| Core | Formerly called xosNgLib, contains a set of UI components to render table, forms, ... |
| [DataSources](./data-sources.md) | Is the actual glue between the UI and the data model. It use a combination of REST API and Websocket to return data as Observables. |
| Extender | It is responsible to extend the application with custom extension provided by services |
-| Service Graph | It's job is to read the service definition from the backend and represent it in a visual form, both at system and subscriber level |
\ No newline at end of file
+| Service Graph | It's job is to read the service definition from the backend and represent it in a visual form, both at system and subscriber level |
+
diff --git a/docs/developer/README.md b/docs/developer/README.md
index c4b57de..49709fc 100644
--- a/docs/developer/README.md
+++ b/docs/developer/README.md
@@ -1,6 +1,10 @@
# Developer Guide
In order to contribute to the XOS-GUI you'll need to have few tools installed:
-- [Vagrant](https://www.vagrantup.com/)
-- [NodeJs](https://nodejs.org/en/)
-- [repo](https://code.google.com/p/git-repo/) You can find instructions on the [wiki](https://wiki.opencord.org/display/CORD/Getting+the+Source+Code)
\ No newline at end of file
+
+* [Vagrant](https://www.vagrantup.com/)
+* [NodeJs](https://nodejs.org/en/)
+* [repo](https://code.google.com/p/git-repo/)
+
+You can find instructions on the [wiki](https://wiki.opencord.org/display/CORD/Getting+the+Source+Code)
+
diff --git a/docs/developer/gui_extensions.md b/docs/developer/gui_extensions.md
index 52bf7f7..1808aa5 100644
--- a/docs/developer/gui_extensions.md
+++ b/docs/developer/gui_extensions.md
@@ -1,60 +1,78 @@
# Creating a custom GUI Extension
-
-The CORD GUI is designed to be extensible. There are two cases in which we envision an extension to be needed:
-- Provide a different view over data
-- Create custom interfaces for services
-
+
+The CORD GUI is designed to be extensible. There are two cases in which we
+envision an extension to be needed:
+
+* Provide a different view over data
+* Create custom interfaces for services
+
The development process for both is the same.
-
-## Starting Development
+
+## Starting Development
### Option 1: Use the provided Yeoman xos-gui-extension generator
-The provided generator in `generator-xos-gui-extension` will generate a new GUI extension for you with the name of
-your choice and demo components based on a simplified `sample-gui-extension`. No refactoring necessary.
+The provided generator in `generator-xos-gui-extension` will generate a new GUI
+extension for you with the name of your choice and demo components based on a
+simplified `sample-gui-extension`. No refactoring necessary.
#### Prerequisites
-You must have the Yeoman toolset installed via npm on your system. It can be installed by running `npm install --global yo`.
-If you encounter any issues, full detailed instructions on installation can be found at the [Yeoman website](http://yeoman.io/codelab/setup.html).
+
+You must have the Yeoman toolset installed via npm on your system. It can be
+installed by running `npm install --global yo`.
+
+If you encounter any issues, full detailed instructions on installation can be
+found at the [Yeoman website](http://yeoman.io/codelab/setup.html).
#### Installation
-Once you have successfully installed Yeoman, run the following to install the generator.
+
+Once you have successfully installed Yeoman, run the following to install the
+generator.
+
```bash
cd ~cord/orchestration/xos-gui/generator-xos-gui-extension
npm link
```
-To run the generator, simply run `yo xos-gui-extension` from whatever location in your file system you wish to place your
-new GUI extension. The extension will prompt for a name for your extension.
+To run the generator, simply run `yo xos-gui-extension` from whatever location
+in your file system you wish to place your new GUI extension. The extension
+will prompt for a name for your extension.
### Option 2: Copy over sample-gui-extension
-If you choose not to use the Yeoman generator, you can copy over the contents of `sample-gui-extension` to your desired
-destination in your file system. If you are creating a GUI extension to used with a service, we suggest creating the
-extension in a folder named `gui` in the service's `xos` folder as follows: `orchestration/xos_services/service_name/xos/gui/`.
-When changing the name of `sample-gui-extension`, you must be wary to change all instances of `sample-gui-extension` in the
-extension folder.
-
+If you choose not to use the Yeoman generator, you can copy over the contents
+of `sample-gui-extension` to your desired destination in your file system. If
+you are creating a GUI extension to used with a service, we suggest creating
+the extension in a folder named `gui` in the service's `xos` folder as follows:
+`orchestration/xos_services/service_name/xos/gui/`. When changing the name of
+`sample-gui-extension`, you must be wary to change all instances of
+`sample-gui-extension` in the extension folder.
+
## Adding an extension to the build system
-
-To deploy your GUI extension with a cord profile you'll need to reference it in `platform-install` and `build`.
-The following steps must be followed to ensure that your GUI extension builds correctly with XOS.
+
+To deploy your GUI extension with a cord profile you'll need to reference it in
+`platform-install` and `build`. The following steps must be followed to ensure
+that your GUI extension builds correctly with XOS.
### Adding the extension to `docker_images.yml`
-Open `cord/build/docker_images.yml`. Locate the section of the file with other GUI extensions, and add the following:
+Open `cord/build/docker_images.yml`. Locate the section of the file with other
+GUI extensions, and add the following:
```yaml
- name: xosproject/gui-extension-sample
repo: sampleRepo # should match Gerrit repo name
path: "xos/gui" # path to find extension in the repo (i.e. sampleRepo/xos/gui/)
```
-Please maintain ascending alphabetical order among the GUI extensions when inserting your own extension.
+
+Please maintain ascending alphabetical order among the GUI extensions when
+inserting your own extension.
### Adding the extension to the podconfig scenario
-Open the `config.yml` file of the podconfig scenario relevant to your GUI extension (e.g. cord, mock, local).
-Locate the section titled `docker_image_whitelist` and add your GUI extension.
+Open the `config.yml` file of the podconfig scenario relevant to your GUI
+extension (e.g. cord, mock, local). Locate the section titled
+`docker_image_whitelist` and add your GUI extension.
```yaml
docker_image_whitelist:
@@ -67,23 +85,30 @@
```
### Adding the extension to the podconfig profile manifest
-
-Open the `profile-manifest` relevant to the podconfig you're working on (eg: profile_manifests/frontend.yml) and locate `enabled_gui_extensions`.
-It may appear in two forms, depending whether or not there are others loaded extensions:
+
+Open the `profile-manifest` relevant to the podconfig you're working on (eg:
+profile_manifests/frontend.yml) and locate `enabled_gui_extensions`. It may
+appear in two forms, depending whether or not there are others loaded
+extensions:
+
```yaml
enabled_gui_extensions:
- name: sample
path: orchestration/xos-sample-gui-extension
```
-or:
+
+or:
+
```yaml
enabled_gui_extensions: []
```
-_NOTE: if it is not there, just create it._
+
+> NOTE: if it is not there, just create it.
### Change conf export settings to match extension name
To add your extension, just add it to the list:
+
```yaml
enabled_gui_extensions:
- name: sample
@@ -91,9 +116,13 @@
- name: myextension
path: orchestration/myextension
```
-_NOTE: if it was defined as an empty array you'll need to remove the square brackets (`[]`)_
-You must make sure that the `name` field matches the directory in which the GUI Extension is built. You can update it in `conf/gulp.conf.js`.
+> NOTE: if it was defined as an empty array you'll need to remove the square
+> brackets (`[]`)
+
+You must make sure that the `name` field matches the directory in which the GUI
+Extension is built. You can update it in `conf/gulp.conf.js`.
+
```js
exports.paths = {
src: 'src',
@@ -104,18 +133,22 @@
tasks: 'gulp_tasks'
};
```
-and replace `sample` with your appropriate name. If you used the Yeoman generator, `sample` will already have been
-replaced with the GUI extension name you chose.
-The `path` field identifies the directory (starting from the CORD `repo` root), in which your extension is stored.
-Loading from external sources is not currently supported.
+and replace `sample` with your appropriate name. If you used the Yeoman
+generator, `sample` will already have been replaced with the GUI extension name
+you chose.
+
+The `path` field identifies the directory (starting from the CORD `repo` root),
+in which your extension is stored. Loading from external sources is not
+currently supported.
## Additional Tips
### Including Extra Files
-Additional necessary files (such as stylesheets or config files) can be added to the profile manifest as follows,
-with the extension's `src` folder as the root. Here, we use `xos-sample-gui-extension` as an example.
+Additional necessary files (such as stylesheets or config files) can be added
+to the profile manifest as follows, with the extension's `src` folder as the
+root. Here, we use `xos-sample-gui-extension` as an example.
```yaml
enabled_gui_extensions:
@@ -127,11 +160,14 @@
### Generating config files
-During development, you may find it necessary to create separate config files in order to include other files used in
-your extension (such as images). The path to your extension may vary depending on whether you are running it locally
-(`./xos/extensions/extension-name`) vs. on a container in production (`./extensions/extension-name`).
+During development, you may find it necessary to create separate config files
+in order to include other files used in your extension (such as images). The
+path to your extension may vary depending on whether you are running it locally
+(`./xos/extensions/extension-name`) vs. on a container in production
+(`./extensions/extension-name`).
-You can create separate `customconfig.local.js` and `customconfig.production.js` files in the `conf/` folder, and then edit the
+You can create separate `customconfig.local.js` and
+`customconfig.production.js` files in the `conf/` folder, and then edit the
following portion of the appropriate `webpack.conf.js` file as follows:
```js
@@ -143,29 +179,41 @@
])
```
-`webpack.conf.js` will be used in a local development environment, such as when running `npm start`
+`webpack.conf.js` will be used in a local development environment, such as when
+running `npm start`
-`webpack-dist.conf.js` will be used in a production container after deploying a profile.
+`webpack-dist.conf.js` will be used in a production container after deploying a
+profile.
### Handy XOS Components and Services
-The following XOS components and services may be helpful to you in your GUI extension development.
+The following XOS components and services may be helpful to you in your GUI
+extension development.
#### XosComponentInjector
-Allows for the injection of components into the XOS GUI by specifying a target element ID. Useful IDs include:
+
+Allows for the injection of components into the XOS GUI by specifying a target
+element ID. Useful IDs include:
+
* `#dashboard-component-container`: the dashboard as seen on the XOS home
-* `#side-panel-container`: a side panel that can slide out from the right. However, there is also a `XosSidePanel`
-service that can make development easier.
+* `#side-panel-container`: a side panel that can slide out from the right.
+ However, there is also a `XosSidePanel` service that can make development
+ easier.
#### XosConfirm
-Allows for the creation of confirmation modal dialogs to confirm whether or not to execute a selected action.
+
+Allows for the creation of confirmation modal dialogs to confirm whether or not
+to execute a selected action.
#### XosKeyboardShortcut
-Allows for the creation of custom user keyboard shortcuts. See the provided `components/demo.ts` as an example.
+
+Allows for the creation of custom user keyboard shortcuts. See the provided
+`components/demo.ts` as an example.
#### XosModelStore
-Provides easy access to model ngResources provided by an XOS service. Can be used as follows in your component's
-associated TypeScript file:
+
+Provides easy access to model ngResources provided by an XOS service. Can be
+used as follows in your component's associated TypeScript file:
```typescript
import {Subscription} from 'rxjs/Subscription';
@@ -176,7 +224,7 @@
constructor(
private XosModelStore: any,
){}
-
+
$onInit() {
this.modelSubscription = this.XosModelStore.query('SampleModel', '/sampleservice/SampleModels').subscribe(
res => {
@@ -193,8 +241,11 @@
```
#### XosNavigationService
+
Used to create custom navigation links in the left navigation panel.
#### XosSidePanel
-Makes the injection of a custom side panel somewhat easier (no need to specify a target)
+
+Makes the injection of a custom side panel somewhat easier (no need to specify
+a target)
diff --git a/docs/developer/quickstart.md b/docs/developer/quickstart.md
index a27c800..6e94799 100644
--- a/docs/developer/quickstart.md
+++ b/docs/developer/quickstart.md
@@ -1,63 +1,82 @@
# GUI Quickstart
-_We assume that you already have the CORD source downloaded with `repo`_
+> NOTE: We assume that you already have the CORD source downloaded with `repo`
## Setting up a podconfig
-For front-end development, using a podconfig with your choice of CORD flavors and the `mock` or `local` scenario is sufficient.
-`mock` will create a vagrant VM running all the necessary containers, while `local` directly creates the containers on your machine,
-so we recommend using `mock` when developing on your own laptop/desktop.
+For front-end development, using a podconfig with your choice of CORD flavors
+and the `mock` or `local` scenario is sufficient. `mock` will create a
+vagrant VM running all the necessary containers, while `local` directly creates
+the containers on your machine, so we recommend using `mock` when developing on
+your own laptop/desktop.
-Assuming you have already downloaded and ran the `cord-bootstrap.sh` script, setup is easy:
+Assuming you have already downloaded and ran the `cord-bootstrap.sh` script,
+setup is easy:
```bash
cd ~/cord/build/
make PODCONFIG={CORD_FLAVOR}-mock.yml config
make build |& tee ~/build.out
-```
+```
-Further details on the mock configuration and its setup can be found at [Mock Configuration Workflow](/xos/dev/workflow_mock_single.md)
+Further details on the mock configuration and its setup can be found at [Mock
+Configuration Workflow](/xos/dev/workflow_mock_single.md)
### Login credentials
-After the mock profile finishes building, you can find the credentials necessary to login into XOS by running the following:
-```
+After the mock profile finishes building, you can find the credentials
+necessary to login into XOS by running the following:
+
+```shell
cat ~/cord/build/platform-install/credentials/xosadmin@opencord.org
// save the output somewhere
```
## Serving the GUI in development mode
-Once your basic CORD config is up and running you should be able to access the GUI at `http://192.168.46.100/xos/`.
+Once your basic CORD config is up and running you should be able to access the
+GUI at `http://192.168.46.100/xos/`.
-NOTE: This is not your development copy, it is the one deployed inside a container in XOS and will not change until
-the container is torn down and redeployed.
+NOTE: This is not your development copy, it is the one deployed inside a
+container in XOS and will not change until the container is torn down and
+redeployed.
To launch a development copy:
-```
+
+```shell
// back to your local system
cd cord/orchestration/xos-gui
npm install
npm start
```
-It will open your default browser at `localhost:3000`, proxy your API request to the local environment and watch for file changes.
+It will open your default browser at `localhost:3000`, proxy your API request
+to the local environment and watch for file changes.
-**Now you're ready to start working on it!**
+Now you're ready to start working on it!
-To get start, login using username `xosadmin@opencord.org` and the password you previously saved,
-then pick any file and make a change, and you'll see the GUI reload.
+To get start, login using username `xosadmin@opencord.org` and the password you
+previously saved, then pick any file and make a change, and you'll see the GUI
+reload.
## Configuring the `dev` GUI
-There are two configuration file available in the application, and they depend on the environment. You can find the various possibilities in `conf/app`, and they regard application constants, such as `apiEndpoint`, or branding elements, such as `projectName`.
+There are two configuration file available in the application, and they depend
+on the environment. You can find the various possibilities in `conf/app`, and
+they regard application constants, such as `apiEndpoint`, or branding elements,
+such as `projectName`.
To load a different configuration file you can use two environment variables:
-- `PROXY`: you can use this variable to send request to an arbitrary XOS installation (eg: `clnode022.clemson.cloudlab.us:8080`)
-- `BRAND`: to configure style constants (eg: `cord`, `opencloud`)
+
+* `PROXY`: you can use this variable to send request to an arbitrary XOS
+ installation (eg: `clnode022.clemson.cloudlab.us:8080`)
+
+* `BRAND`: to configure style constants (eg: `cord`, `opencloud`)
## Working with an existing XOS installation
-You can also specify a different installation of XOS as backend by using the `PROXY` environment variable.
-For example, you can connect to a remote CORD-in-a-box installation for debugging purposes with:
+You can also specify a different installation of XOS as backend by using the
+`PROXY` environment variable. For example, you can connect to a remote
+CORD-in-a-box installation for debugging purposes with:
`PROXY=ms1106.utah.cloudlab.us:8080 npm start`
+
diff --git a/docs/developer/service_graph.md b/docs/developer/service_graph.md
index caf076c..6b785f9 100644
--- a/docs/developer/service_graph.md
+++ b/docs/developer/service_graph.md
@@ -1,64 +1,73 @@
# How to operate on the Service Graph
-The service graph enable some features to simplify operators daily tasks,
-here is a quick guide on how to use those fetaures.
+The service graph enable some features to simplify operators daily tasks, here
+is a quick guide on how to use those fetaures.
## Adding informations to the graph
-The Service Graph will render by default only the `Services`, but you can augment
-the available information by pressing:
+The Service Graph will render by default only the `Services`, but you can
+augment the available information by pressing:
-- `Shift + f` toggle fullscreen mode
-- `Shift + s` to add `ServiceInstances` to the graph
-- `Shift + i` to add `Instances` to the graph (this require `ServiceInstances` to be shown)
-- `Shift + n` to add `Networks` to the graph (this require `Instances` to be shown)
+* `Shift + f` toggle fullscreen mode
+* `Shift + s` to add `ServiceInstances` to the graph
+* `Shift + i` to add `Instances` to the graph (this require `ServiceInstances`
+ to be shown)
+* `Shift + n` to add `Networks` to the graph (this require `Instances` to be
+ shown)
## Define the position of the Services in the graph
-XOS define a model called `ServiceGraphConstraint`,
-that let you enforce constraints on the nodes position.
+XOS define a model called `ServiceGraphConstraint`, that let you enforce
+constraints on the nodes position.
Here is a basic of how it works:
-#### Setting the services on a line
+### Setting the services on a line
```json
["a", "b", "c"]
```
+
will position the nodes as:
-```
+
+```graph
a -> b -> c
```
-#### Services as a tree
+### Services as a tree
```json
["a", ["b", "c"]]
```
+
will position the nodes as:
-```
+```graph
b
/
- a
+ a
\
c
```
-#### Empty spots in the graph
+### Empty spots in the graph
+
```json
[[null, "a"], ["b", "c"]]
```
+
will position the nodes as:
-```
+```graph
b
- |
+ |
a -> c
```
-_Note that all the notes not defined in the `ServiceGraphConstraint` model will float around_
+> NOTE: All the notes not defined in the `ServiceGraphConstraint` model will
+> float around
## Events listened by the Service Graph
-- `xos.sg.update` will render the graph again
\ No newline at end of file
+* `xos.sg.update` will render the graph again
+
diff --git a/docs/developer/tests.md b/docs/developer/tests.md
index 9e4ffa1..04af0fa 100644
--- a/docs/developer/tests.md
+++ b/docs/developer/tests.md
@@ -2,38 +2,48 @@
## Unit Tests
-There is a quite extensive suite of Unit Tests that are provided along with the code to help your development.
+There is a quite extensive suite of Unit Tests that are provided along with the
+code to help your development.
-These tests are defined using [Karma](https://karma-runner.github.io/1.0/index.html) as test runner and [Jasmine](https://jasmine.github.io/) as assertion library. Test are defied along with the code, you can look for any `.spec.ts` file in the source tree.
+These tests are defined using
+[Karma](https://karma-runner.github.io/1.0/index.html) as test runner and
+[Jasmine](https://jasmine.github.io/) as assertion library. Test are defied
+along with the code, you can look for any `.spec.ts` file in the source tree.
You can execute them in two flavors:
-- Single run (this is the same flavor that is used on Jenkins): `npm test`
-- Watch mode: `npm run test:auto`
-While developing the GUI we'll suggest you to run the test in watch mode, and they'll be executed anytime a file changes. It will help you in catchings bugs immediately. It also provide more information on which tests are executed.
+* Single run (this is the same flavor that is used on Jenkins): `npm test`
+* Watch mode: `npm run test:auto`
+
+While developing the GUI we'll suggest you to run the test in watch mode, and
+they'll be executed anytime a file changes. It will help you in catchings bugs
+immediately. It also provide more information on which tests are executed.
## End to End Tests
-There is a suite of basic end to test that are defined using [protractor](http://www.protractortest.org/#/), an AngularJs oriented version of Selenium.
+There is a suite of basic end to test that are defined using
+[protractor](http://www.protractortest.org/#/), an AngularJs oriented version
+of Selenium.
These tests can be found in the `e2e` folder.
-_NOTE: Require protractor to be installed as a global module._
+> NOTE: Require protractor to be installed as a global module.
### Setup
-```
+
+```shell
webdriver-manager update
webdriver-manager start
```
-### Run the tests
+#### Run the tests
-_Note that this tests are designed to work with the Mock R-CORD config_
+> NOTE: These tests are designed to work with the Mock R-CORD config
+```shell
+protractor conf/protractor.conf.js
```
-protractor conf/protractor.conf.js
-```
-
+
Other paramenters you can pass are:
| Variable Name | Description |
@@ -41,11 +51,12 @@
| UI_URL | Address of the GUI (deaults to `http://192.168.46.100/spa/#` |
| UI_PWD | Password to login (needed only for remote connections) |
| TIMEOUT | Time allowed for each test |
-
- #### Test suites
-
- If you need to run test for only a particural suite you can use:
-
- `protractor conf/protractor.conf.js --suite login`
-
- Suites are defined in `cong/protractor.conf.js`
\ No newline at end of file
+
+### Test suites
+
+If you need to run test for only a particural suite you can use:
+
+`protractor conf/protractor.conf.js --suite login`
+
+Suites are defined in `cong/protractor.conf.js`
+