Status

Glass Loader

Web Trust Loader for Blueprint based Distributed Apps

Installation

In order to use the glass-toolkit package, we need to follow a list of steps presented below.

Step 1: Install as Dependency (via npm)

Step 1.1: Dependencies

This package has the following dependencies of other @glass-project packages:

• @glass-project/db-decorators,
• @glass-project/decorator-validation,
• @glass-project/dsu-blueprint,
• @glass-project/dsu-utils,
• @glass-project/key-sharding,
• @glass-project/logging,
• @glass-project/ui-decorators
• @glass-project/ui-decorators-web
• @glass-project/trust-loader
• @glass-project/blueprint-loader

All of them need to be installed via npm install --save-dev. (Saving has a proper dependency is also supported but not advised since it breaks modularization, and creates duplication of interior scopes)

Step 1.2: Install

To install as a dependency do:

$ npm install @glass-project/glass-loader

To install as a dev dependency do:

$ npm install @glass-project/glass-loader --save-dev

instead.

Step 1 (Alternative): Install via Octopus

If you are working on an OpenDSU workspace and require easy access to the source code, you can also clone from the source and rebuild it from source.

Step 1.1: Add Octopus as a npm dependency (it should already be there)

Octopus is an OpenDSU related TaskRunner with some integrations with the OpenDSU Framework

add to you package.json, under the devDependencies:

{
  "devDependencies": {
    "octopus": "git+https://github.com/PrivateSky/octopus.git"
  }
}

in both the octopus.json and octopus-freeze.json add:

• under dependencies:

    {
      "name": "glass-loader",
      "src": "https://gitlab.ubitech.eu/glass-project/wallet/glass-loadert.git",
      "actions": [
        {
          "type": "smartClone",
          "target": ".",
          "collectLog": false
        },
        {
          "type": "execute",
          "cmd": "cd glass-loader && npm install"
        }
      ]
    }

• under build:

    {
      "name": "build glass-loader",
      "src": ".",
      "actions": [
        {
          "type": "execute",
          "cmd": "cd glass-loader && npm run build:loader"
        }
      ]
    }

This will instruct the taskrunner on how to build the repository, and tell it to also include it in its install and build-all tasks.

You can now import the code under ./glass-toolkit/lib

Repository Structure

glass-laoder
│
│   .gitignore              <-- Defines files ignored to git
│   .gitlab-ci.yml          <-- GitLab CI/CD config file
│   .nmpignore              <-- Defines files ignored by npm
│   .nmprc                  <-- Defines the Npm registry for this package
│   gulpfile.js             <-- Gulp build scripts. used to clean the stencil output bundles from leftover opendsu imports
│   jsdocs.json             <-- Documentation generation configuration file
│   LICENCE.md              <-- Licence disclamer
│   nodemon.json            <-- Nodemon config file (allows to live test ts files)
│   package.json
│   package-lock.json
│   README.md               <-- Readme File dynamically compiled from 'workdocs' via the 'docs' npm script
│   stencil.config.js       <-- Stencil configuration file
│   tsconfig.json           <-- Typescript config file. Is overriden in 'gulpfile.js' 
│   ionic.config.json       <-- Ionic app config
│
└───bin
│   │   tag_release.sh      <-- Script to help with releases
│   
└───docs
│   │   ...                 <-- Dinamically generated folder, containing the compiled documentation for this repository. generated via the 'docs' npm script
│   
└───src
│   │   ...                 <-- Source code for this repository
│   
└───workdocs                <-- Folder with all pre-compiled documentation
│    │   ...
│    │   Readme.md          <-- Entry point to the README.md   
│
└───www
     |  ...                 <-- Dinamically generated folder containing the actual code that should go into the loader folder

How does it work?

Upon loading you are presented with a login/registration screen.

Upon registering, the Loader will create a new Wallet instance, anchor it to the blockchain, and install the predefined dApp(s) onto it.

When you login, the loader will retrieve the Wallet you had previously created, load the DSU, instantiate a new iframe use it as a container to the newly loaded SSApp.

How to adapt the form?

TODO

dApp Loading and Configuration

PWA capabilities

The current setup is configured to ensure that the web application is 100% compatible with the PWA standard. For a detailed guide please check here.

Development flow

!!! To ensure a correct functionality, anytime a static file changes inside the current project, a new service worker must be generated. !!! The service worker keeps a list of each file that is registered for caching (defined inside workbox-config.js) along with its revision. The file revision represents a hash generated based on the file content. The following command must be run after any of the tracked file changes:

npm run build

Changes that must be made on the current setup

• Every time the URL at which the application is available changes, the following changes must be made:

  1. manifest.webmanifest
  • scope: defines the navigation scope of this web application's context
    • usually it's the root URL, e.g.: /secure-channels/loader/
    • if the scope is a relative URL, the base URL will be the URL of the manifest.
  • start_url: represents the start URL of the web application
    • cannot be outside of scope, usually it's the same as scope, e.g.: /secure-channels/loader/
    • if the URL is relative, the manifest URL is used as the base URL to resolve it.
  2. index.html
  • when the service worker is registered, the scope should be the same as the scope defined inside manifest.webmanifest
  • the line const wb = new Workbox("swPwa.js", { scope: "/secure-channels/loader/" }); should have the correct scope specified

• Every time the color scheme and/or application images changes, the following changes must be made:

  • manifest.webmanifest
    • icons
    • background_color
    • theme_color
  • index.html
    • meta theme-color
    • links rel="apple-touch-icon"
    • links ref="apple-touch-startup-image"

• In order to detect when a service worker must update its cached files, a regular check is made in order to see if another service worker is available. Each time an update is available, the user will receive a confirmation popup notifying him that a new update is available and to confirm if he wants to reload in order to see the changes. In the current setup the check is done every minute. In order to change the confirmation popup, the showNewContentAvailable method should be changed inside index.html. To change the check interval, inside the index.html file the following should be updated:

setInterval(() => {
  wb.update();
}, 60 * 1000);

Repository Languages

Social

Disclaimer: