Access to the current running instance of the Application can be found on http://my-edb.herokuapp.com. There are three tools available: Products DB, Nutrition DB and EDB-Prose. How to work with the Eaternity database:
_data/prods
or _data/nutrs
-> repository_data/prod
directory. You will see a list of all existing products.New File
button.<id>-<name>-prod.json
.{ "id": <id>, "name": "<name>"
. Make sure you put the name in double quotes ("") but not the id.The Eaternity Database is a collection of files and tools.
This is a schematic overview on the whole EDB solution:
There are three different physical locations involved: Heroku.com, GitHub.com und the local computer. Whereas the website's content is stored in a repository on GitHub.com at https://github.com/Eaternity/eaternity-database-public, the website itself is hosted on and served from an app running at Heroku.com under the URL https://my-edb.herokuapp.com. When new changes are pushed to the repository on GitHub.com, the Jekyll server running at Heroku.com is automatically notified, the website is rebuilt and after a few minutes the changes are reflected to the user. The GitHub repository is private. GitHub's gh-pages
branch is never used, because everything published under a gh-pages
branch is accessible to the whole world. The repository belongs to a GitHub organization Eaternity. This organization has a team edb-website-users. All members of this team have admin access to the eaternity-database-public repository, and only members of this team will be allowed to access the website and read or write data through it.
The website including all files are stored in a GitHub repository available in the master
branch. The website consists of three different sets of files - all more or less mingled together:
_data/prod
, _data/nutr
etc. directories.prose
directory, the file prose/index.html
expects a few other Javascript files to exist one level above it, i.e. in prose/../..
.When a user makes any changes to the local clone of the GitHub repository, he then adds git add...
, commits git commit -m "blah"
and pushes git push
these changes to the remote GitHub repository. A webhook is available for the eaternity-database-public repository, and it is through this webhook that the Jekyll server running on Heroku is informed about pending updates. The Heroku server process grabs the changed files from the GitHub repository and rebuilds the whole website. (The whole process usually takes several minutes.) This automatic deployment from GitHub's repo to Heroku's repo is set up using a GitHub integration feature for Heroku apps. To see the current settings, log in to the Heroku Dashboard as <owner of my-edb Heroku app> and click on the Deploy menu item. (The GitHub integration feature is currently in beta status. An older, but still working alternative would be to use Heroku deployer, but this is more difficult to set up).
The Heroku server process has its own Git repository available under code>git@heroku.com:my-edb.git</code, but this repository should not be pushed to with git push heroku master
in most cases. The reason is that the corresponding "sibling" repository on GitHub eaternity-database-public will of course not be notified of any changes made to Heroku.
When a user tries to access the website available under https://my-edb.herokuapp.com several things happen in sequence.
Eaternity/eaternity-database-public/_data/prod/1234-bla-prod.json
in the GitHub repository. A second authorization/authentication is triggered at this step, which is independent of the first one performed earlier. Whereas through the first authorization/authentication procedure website access is controlled, the second controls access of the user to any data file on the GitHub repository through EDB Prose. Therefore, first the edb-prose-gatekeeper app requests the user's credentials, which are by now probably stored locally in a session cookie. These credentials are sent to GitHub, and GitHub returns ok/nok for this user.Every product is stored in the JSON data format in a file with a filename of <id>-<product-name>-prod.json
. For nutrition files the filename is <id>-<nutrition-name>-nutr.json
.
All files are placed in a _data/prods/
resp. _data/nutr/
subdirectory in the gh-pages branch of the project. All YAML- or JSON-files placed in such a subdirectory can be accessed and looped over via Liquid templates:
{% for prod in site.data.prods %} ...do something... {% endfor %}
.
The variable prod[0]
will contain the filename (without leading path and without file ending), whereas prod[1]
will contain the key/value-pairs specified in YAML or JSON.
It is now easy to build a HTML page containing a list of all ingredients with selected attributes:
...
<ul>
{% for prod in site.data.prods %}
<li>Filename: {{ prod[0] }}.json; name: {{ prod[1].name }}</li>
{% endfor %}
</ul>
...
Jekyll-DB is an open source and easy-to-use tool based on List.js to index, filter, search, sort and display html tables and lists. Basically, Jekyll-DB always processes a file's frontmatter, which might be prepended in either YAML or JSON format. The file itself must be in the _posts
(or _data
) directory and be recognized by Jekyll as a valid post, i.e. it must have a valid file ending for markdown (.md, .markdown) or html (.html, .htm) posts. From a file's frontmatter, Jekyll-DB builds an adaptable display table that can be searched and filtered by keywords and sorted by columns. It is also possible to place links in the display table e.g. to a open a given post item in a GitHub or Prose editor. Data columns can be specified, as can the number of displayed items. (This feature requires Jekyll-DB > v2.1.0.)
Although the official documentation does not state it explicitly, Jekyll-DB not only works with YAML/JSON-frontmatter of files placed inside a _posts
directory, but also with YAML/JSON-files in a _data/prods/
(or _data/nutrs/
) subdirectory. If a _posts/
directory is used, in Liquid templates frontmatter data can be accessed directly, e.g. {% for post in site.posts %} ...{{ post.myFrontmatterKey }}... {% endfor %}
. For _data/prods/
subdirectories, additionally indices must be used to differentiate between filename at index 0 and frontmatter content at index 1: {% for prod in site.data.prods %} ...{{ edb[1].myFrontmatterKey }}... {% endfor %}
.
If JSON files inside a _data
subdirectory should be indexed, a Jekyll server instance >= v.2.1.0 is required. Indexing frontmatter only in a _posts
directory also works with older Jekyll server instances. Re-indexing all -prod.json files on Github can take 30 seconds to a few minutes.
To add new columns or remove existing ones, follow the steps described in Jekyll-DB's README file.
Whereas Jekyll-DB allows to display data, Prose can be used to actually edit the underlying data. Prose is an open-source editor built on top of GitHub pages. There is a free-to-use online instance running at the given link, but it is also possible to run one's own Prose in any YAML-aware webserver such as Jekyll or a Node.js web server.
We use an adapted version of prose which additionally supports files with file names ending on -prod.json
or -nutr.json
. Such files are expected to be in the EDB JSON data format. Opening such a file in the adapted version of Prose will automatically open a JSONForm editor window.
A user must be able to authorise access of Prose (or any descendant) to his/her Github repositories. For this purpose, besides installing and running Prose, also a gatekeeper server must be installed and run on Heroku. The basic steps are:
GitHub applications such as Prose need to follow the OAuth procedure for authentication. Thus, we need to register a new OAuth application on GitHub. As a result, we will receive a clientId (e.g. da429541964e3302c62f) and a client secret (another string consisting of random numbers and letters). This is the information which will be required by the gatekeeper instance.
In the case of Prose, a dedicated gatekeeper server is needed for the OAuth procedure with GitHub to work. This server is neither provided by GitHub nor can it be run on GitHub and therefore must be set up manually externally. For this purpose, we need a (free) repository on Heroku, there we will run our own gatekeeper server. We register a new account at Heroku. At this time, there is no need to set up a sample application.
Next, we need to install our own gatekeeper server on Heroku. The installation steps are described in Prose's documentation on Gatekeeper. Here they are:
git clone git@github.com:prose/gatekeeper.git
cd gatekeeper && npm install
cake
, therefore this step can be skipped. Nevertheless, here's an up-to-date version of how the config.json file should look like.)
{
"oauth_client_id": "da429541964e3302c62f",
"oauth_client_secret": "XXX",
"oauth_host": "github.com",
"oauth_port": 443,
"oauth_path": "/login/oauth/access_token",
"oauth_method": "POST"
}
We do not want to run the gatekeeper server locally and directly continue to the deployment on Heroku. gatekeeper> heroku create
gatekeeper> heroku apps:rename my-edb-prose-gatekeeper
gatekeeper> heroku config:set OAUTH_CLIENT_ID=da429541964e3302c62f OAUTH_CLIENT_SECRET=XXX
gatekeeper> git push heroku master
In our case, we chose to use the name "my-edb-prose-gatekeeper" for our application, which will result in an url of http://my-edb-prose-gatekeeper.herokuapp.com. The client secret will not bo provided here but must be taken from GitHub's application registration procedure. The gatekeeper server should now be up and running. This can be checked in our Heroku account.
We are now ready to rebuild our adapted version of Prose, so that authorisation through gatekeeper runs smoothly.
{
"api": "https://api.github.com",
"site": "https://github.com",
"clientId": "da429541964e3302c62f",
"gatekeeperUrl": "https://my-edb-prose-gatekeeper.herokuapp.com"
}
Once we've made our changes, we rebuild prose.js/prose.min.js with the commands make clean
and make
. Note that the file oauth.json is added to .gitignore
and will not be uploaded to the server. Instead, during the build process the file's contents are read out and appended to prose.js/prose.min.js. (Attention: Using the make command in Windows is cumbersome, as this presumes an installation of a make-tool, e.g. the one provided by cygwin. After installation, the make commands must be run manually. Still this somehow results in problems, because after these steps the modified Prose cannot be started with jekyll serve
anymore, but only with npm's serve
command. If using Jekyll, an error message is thrown: _jekyll 2.1.0 | Error: undefined method 'defaultproc=' for "this --- is correct":String.)
Adding a new data type (e.g. -proc.json) to Prose and JSONForm requires the manipulation of several files. After the manipulation, Prose must be rebuilt using a make command.
Manipulation of Prose requires the adaptation of 4 files:
eaternity-database-public/prose/app/util.js
: Recognizes data files by their endings. All we add is an isProc
function comparable to the already existing isProd
and isNutr
functions.eaternity-database-public/prose/app/models/file.js
: Inside the initialize
function we have to register the statement 'proc': util.isProc(path),
.eaternity-database-public/prose/app/views/file.js
: Inside the initEditor
function we have to specify to open the JSONForm editor instead of the default editor for -proc.json
files. Inside the render
function, the edit
function and the showDiff
function we add some statements for the new proc files.eaternity-database-public/prose/app/views/jsonformformat.js
: We need to add a schema- and form-definition as specified in the JSONForm docs.In case you would like to create dropdown menus in JSONForm, you will probably have to set up additional Javascript files similar to id-prod.js
and id-nutr.js
. Do not forget to import these Javascript files in Eaternity-Datenbank/prose/index.html
. You can then refer to the list of product ids, nutrition ids or process ids inside the jsonformformat.js file as ID_PROD, ID_NUTR or ID_PROC.
We have made changes to Prose, thus we need to rebuild it. For this purpose, the make
tool is required. Unfortunately, installing make on a Windows machine is quite a pain, and I don't recommend it. Hint: There might exist an alternative to the make command now using gulp.
eaternity-database-public/prose
directory and that make
is in your path. Call make clean
to clean up first.make
to rebuild Prose. There might be warnings, but there should not be an error.Inside the _data
directory, create a new subdirectory, e.g. data/procs
. Therein create a first test file, e.g. -1-test-proc.json_. Add, commit and push the data files to the remote GitHub repository.
Before we push our changes to the server, we would like to try out the new input forms locally. Once we pushed our changes to the server, the new file will be available under the link http://github.com/prose/#Eaternity/eaternity-database-public/edit/gh-pages/_data/proc/-1-test-proc.json. Until then accessing the newly created data files will run through a local Jekyll server instance, thus the link is http://localhost:4000/prose/#Eaternity/eaternity-database-public/edit/gh-pages/_data/proc/-1-test-proc.json.
Next, we want to set up everything in order to present a Jekyll-DB overview page to the user. The set up is fairly simple.
valueNames
variable inside the option
Javascript object at the bottom of the file. Save and exit.Now, if you restart the local Jekyll server with jekyll serve --host localhost
the whole site is rebuilt. This might take a while. The new website is available at http://localhost:4000/index-proc.html resp. will be available at http://my-edb.herokuapp.com/index-proc.html respectively. Add, commit and push your changes to the remote GitHub repository and wait for the site to be rebuilt.
A complete installation guide to Jekyll-Auth can be found here: http://fabian-kostadinov.github.io/2014/11/13/installation-of-jekyll-auth/.