Revision as of 13:25, 20 December 2016

Frontend

ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard front-end implementations, but sites can adapt or implement their own.

The standard frontends are implemented in Bootstrap, jQuery, and Twig, the most popular and well-supported frontend ui component and template systems. This allows for easier customisation of ARK's appearance by third party designers.

The standard frontends shipped with ARK2 are:

• api - The absolute minimal front-end required to run an API-only server, all admin is performed via the admin console.
• admin - A minimal Web Admin frontend for configuring an API-only server
• flat - A simple, non-js, read-only frontend designed for scraping, e.g. for static archiving or web-bots
• core - The default frontend supporting the full ARK2 feature set

File Layout

Build:

/
|- build/
  |- .bowerrc
  |- bower.json
  |- console
  |- gulpfile.js
  |- packages.json
  |- assets/
    |- <name>/
      |- css/
      |- fonts/
      |- img/
      |- js/
      |- less/
      |- scss/
      |- twig/
      |- xliff/
  |- node_packages/
  |- vendor/

Source:

/
|- src/
  |- ARK/
    |- web/
      |- <frontend>/
        |- .htaccess
        |- index.html
        |- templates/
        |- translations/
        |- assets/
          |- fonts/
          |- images/
          |- scripts/
          |- styles/
      |- api/
      |- admin/
      |- core/
  |- <project>/
    |- web/
      |- <frontend>/
        |- ...

Sites:

/
|- sites/
  |- <site>/
    |- config/
    |- files/
    |- schema/
    |- src/
      |- <frontend>/
        |- php/
        |- templates/
        |- translations/
    |- web/
      |- .htaccess
      |- index.php
      |- assets/
        |- <frontend>/
          |- fonts/
          |- images/
          |- scripts/
          |- styles/

Build Tooling

Build tooling is required for a number of reasons:

• Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS
• Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code
• Bower component management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder
• All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc
• The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort

The build tooling will be as follows:

• All build tooling will be isolated in the /build/ folder and will be excluded from any release packages or production deployments
• Nothing in the /build/ folder may be depended on by any code outside the /build/ folder or required for running ARK itself
• Node, npm, Bower and Gulp will be used to run the tooling (Bower requires Node/npm to be installed, so we may as well use its full power)
• Tooling should be cross-platform (Gulp provides this as opposed to bash scripts)
• Gulp will not be required as a global install, instead tasks will be aliased through Node scripts, e.g. 'npm run build' will call 'gulp build'
• Running tasks will only work inside the /build/ folder, trying to run outside the build folder should fail gracefully
• NPM installs Node packages into /build/node_packages/
• Bower will be configured to install external packages into /build/vendor/

Build

The front-end is built from the source assets files in the 'build/' folder and installed in the 'src/' folder. The individual site folders then symlink to the required front-end in 'src/', or copy if they wish to edit in place.

The front end build and install is managed by the build and admin consoles. The build console is in the 'build/' folder and is used to build/rebuild/install a front end if required. The Admin Console is used to link the installed front end to a site.

To build a front end you first need to install the build environment (see Environment for installing the prerequisites):

 ./console build:install

You may occasionally need to update the build environment, especially after an ARK upgrade:

 ./console build:update

To clone the build assets for a new front end from the Core front end, run the create command. You must provide a name for your new front end

 ./console build:frontend:create <frontend>

To build and install a front-end run the front-end command. You can supply a front end name to install or default to the core front end, and optionally a namespace for it to be installed under in 'src/'. Only use the ARK namespace if the front end is intended for the main ARK project.

 ./console build:frontend <frontend=core> <namespace=ARK>

This will install the built front end into 'src/<namespace>/frontend/<frontend>'.

You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don't want to wait for the js to be rebuilt as well:

 ./console build:frontend:css <frontend=core> <namespace=ARK>
 ./console build:frontend:js <frontend=core> <namespace=ARK>
 ./console build:frontend:twig <frontend=core> <namespace=ARK>

To use a front end for a site, run the Admin Console.

To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.

 site:create <site> <frontend> <namespace=ARK>

You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.

To enable a front-end other than core, you will need to edit the '<site>/config/site.json' file to set the name of the front-end.

To add another front-end to a site, or to refresh a copied front-end:

 site:frontend <site> <frontend> <namespace=ARK>

Notes

Bootstrap 3 supports both Less and Sass templates to generate the Bootstrap CSS. Customising the appearance of Bootstrap (such as colour) usually requires modifying template variables and rebuilding the CSS. Bootstrap 4 (currently in alpha) switches to only using SASS for its templates. We should therefore choose to use the SASS version of Bootstrap 3 when building our own custom version of Bootstrap. Build tools will be provided to automate the customisation process.

The use of Twig templates for page layout will help separate the model and view code and allow third parties to easily modify the layout without having to alter the core code. Each Twig template will document the API contract it has with the data model, i.e. what variables are available to be used in the template.

The use of the Silex/Symfony Forms module will be considered. This provides dynamic form generation and validation with a Bootstrap theme.

There will be separation between the ARK Admin frontend and the ARK Web frontend. The required ARK Admin frontend will be static and consistent across all ARKs, but can be modified for site specific requirements if needed (i.e. adding extra user data fields). The optional ARK Web frontend will be the dynamic generated data-driven side, configurable for every ARK. This separation will allow for ARK to run as a pure database/API backend server with basic admin and auth frontend provided without the user having to configure or enable any of the web frontend.

The ARK Admin frontend will provide the core UI elements for the site, i.e. the Nav Bar and Nav Menu. An initial template will be inspired by SB Admin 2 (Test here) and AdminLTE (Test here), but greatly simplified and converted to Twig templates.

• http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works

View Tables/Classes

ark_view_element_type
- Event
- Field
- Layout
- Link
- Subform

ark_view_element
ark_view_field
ark_view_group
ark_view_layout
ark_view_option

Element
- Event
- Field
- Link
- Group
  - Subform
  - Layout
    - Grid
    - Tabbed
    - Table
Alias
Condition
Option
Rule