DigitalCommons / open-data-and-maps

Deprecated: Implementation of Linked Open Data by the Solidarity Economy Association
6 stars 1 forks source link

Make the map-app a self-contained NPM package in its own repository, for ease of re-use #192

Closed wu-lee closed 4 years ago

wu-lee commented 4 years ago

The map-app component of the mini-websites is tangled up with all the other stuff in the open-data-and-maps repository, and uses what seems to be unnecessarily complicated set of makefiles to do its work.

Looking at Matt Wallis' comments in the open-data-and-maps repo wiki, it seems like the intent is that this eventually should be more self-contained such that 3rd parties can use it. For @dtmakm27 and I, this is more of a pressing need because it is hard for us to learn and use as is. Therefore the aim of this ticket is to make it work within the normal javascript toolchain better, i.e. to be an NPM package which can be versioned, deployed and in general used in the same way almost every other JavaScript component is these days.

This does not seem overly difficult, and will also help me to understand the mechanism of the application. (In fact he bulk of the work has been done at the time of writing.)

An additional benefit is that the 3rd party .dotcoop data which has been committed to the repository can be decoupled and made properly private (by making the repository private).

wu-lee commented 4 years ago

The work has been done on a branch npm-ization. This branch is used as the basis of a new repository sea-map (named so because map-app seemed too generic).

Each of the mini websites have had npm-ization branches created which integrate the use of the sea-map NPM package defined by this repository. I've tested them and they seem to work, but I will also be passing this to @dtmakm27 and @ColmMassey to review before merging and closing this issue.

To use it, follow the example of sea-site-experiment.

An overview follows.

The Makefile is no longer required in a mini website, its functions performed by npm and definitions in package.json.

Define your website's project metadata in a file package.json. Specifically, list any required NPM packages (amongst other things). The dependencies should include the sea-map project and semantic version (as defined in the package.json documentation linked above).

Configuration of the sea-map application which used to live in the /map-app/variants/<variant name> subdirectory (like config.json) now go in /config.

Configuration of the sea-map queries and endpoints which used to live in the various /map-app/www/map-app/services/<service name> subdirectory (like config.json) now go in /config/<service name>. There should be one for each service named in config.json's nameDatasets list.

Supplemental assets like custom web pages or images which used to live in the mini-website's /mini-website/src directory now go in /src.

For now, only the minimum changes to the application layout has been made, so that any pending or future changes to the code in /map-app/www of the open-data-and-maps repository can be dropped into the /www directory of sea-map unchanged.

Given the above, npm needs to be installed on the developer's machine, but this is normal for Javascript development. Then the dependencies (including sea-map and requireJS etc.) are pulled in like this:

npm install

If you follow the example script definitions in sea-site-experiment's package.json, the website can be built like this:

npm run build

...Tested from your filesystem on a local development webserver at http://localhost:8080:

npm run dev

(Note, this requires PHP to be installed, specifically the php-cli and php-curl packages on Debian and derived distros. It also assumes the SPARQL endpoints defined in config/<service name>/endpoint.txt are accessible; however after building you can edit build/out/configuration/<service name>/endpoint.txt to change it manually.)

...And deployed to a configurable server:

npm run deploy

Which is everything the makefiles used to do and more, whilst being more concise and built on current standard practices for Javascript development.

It also avoids needing to hard-wire configuration into files committed to the repository (which isn't very convenient if you want to use something different).

More permanent and comprehensive documentation, such advice for configuring deployment, will go in sea-map.

ColmMassey commented 4 years ago

Happy to close this