ontohub / ontohub-frontend

The Ontohub web UI for the end user.

Ontohub

A web-based repository for distributed ontologies, models and specifications.

An ontology is a formal, logic-based description of the concepts and relationships that are of interest to an agent (user or service) or to a community of agents. The conceptual model of an ontology reflects a consensus, and the implementation of an ontology is often used to support a variety of applications such as web services, expert systems, or search engines. Therefore, ontologies are typically developed in teams. Ontohub wants to make this step as convenient as possible. Besides ontologies, Ontohub also supports formal models and specifications, or more generally, logical theories.

Ontohub aims at satisfying a subset of the requirements for an Open Ontology Repository (OOR) and is being developed in close donnection with the Distributed Ontology, Modeling and Specification Language (DOL), which is part of the emerging Ontology, Model and Specification Integration and Interoperability standard (OntoIOp) at OMG. For more information from this perspective, see the Ontohub home page.

This application started at the compact course agile web development given by Carsten Bormann at the University of Bremen in March, 2012. The concept and assignment came from Till Mossakowski, now in Magdeburg and Christoph Lange.

Initial developers are Julian Kornberger and Henning Müller.

Developer- and deployment-centric documentation can be found in the doc/ directory and in our Wiki pages.

Installation

A guide to set up your own instance of ontohub you can find in the deployment guide.

Also a guide for development environment for Mac OS X and Ubuntu in the Wiki.

License

Copyright © 2012 Universität Bremen and Universität Magdeburg, released under the GNU AGPL 3.0 license.

ontohub-frontend's Issues

Create a FAQ page

See #23

axiom filtering

implement axiom filtering due to several criteria, e.g. sublogic analysis (like Protégé does). The filtering should be useable for splitting the OMS.

display analysis errros for OMS

• on the index and show pages, OMS and files with an error should be marked with a symbol
• clicking on the symbol should display the error message
• there should be an error status page, with mist recent errors first

Dasherize all the IDs

Dasherize ids instead of underscore.

Display errors received from the backend

Currently, when there is an error in the backend, we only display a white page or the current page. We should display the error.

See: https://guides.emberjs.com/v2.11.0/routing/loading-and-error-substates/

Remove semicolons where possible

This could be done by adding the semi: ["warn", "never"] rule and using eslint --fix.

Test issue

add instructions for Ubuntu installation

Split development and production dependencies

Currently, we only have development dependencies. To deploy properly, we need production dependencies, because only these will be installed via npm install --production

Use headless Chrome instead/as well as PhantomJS

Chrome/Chromium can now run headless and can be used by testem to run the browser tests. As this is easily configurable and could lead to performance benefits for the tests (no numbers yet, but PhantomJS developers even hinted at creating a new version based on headless Chromium), I don't think there is anything that speaks against it.

I would suggest running both in development mode (ember test --serve) and use PhantomJS OR headless Chromium for CI tests (ember test), as they are run in parallel in development mode, but sequentially in CI mode (so twice the test time).

Extend the git GUI by diffs

As a follow-up on #57, add a diff GUI. diff2html might be a good resource for this task.

Use vcr.js instead of Mirage

Mirage seems to be a lot of work to fit to our API, so we should check if using vcr.js (or similar libraries) is easier to use.

With vcr.js we would run the tests locally and record the API answers for each request. During the CI, this data is read and used. This means that we don't have to explicitly model our API on the frontend as well.

Change page title

Currently the page title (the one in the top/tab bar of the browser) does not change when changing routes.

write wire frames for Ontohub 2.0 concept

see #73. Instead of wire frames, you can also use screenshots of http://staging.ontohub.org/ and extend them.

Provide link to Uni Magdeburg at footer

Write search page tests

Tests for #22.

Dependency version policy

Most dependencies are specified with ^, which means "minor version updates permitted".

I think we should use ~ ("path level updates permitted"), or even specify hard versions. The reasoning for is is that if I install dependencies today, they might be different versions than if I installed them yesterday without a change to the package.json.

While there is something similar to a Gemfile.lock, (npm shrinkwrap can generate this), it's not possible to update versions easily. Basically what you have to do to update a version is:

1. update the package.json
2. delete the node_modules directory
3. run npm install
4. run npm shrinkwrap

If there are packages not specified in the package.json or if there are packages missing that are listed in the package.json, npm shrinkwrap will fail.

The alternative would be to use ~ or specify exact versions in the package.json and use the npm run update script to update to new versions. Also david-dm (the dependency status badge in the README) would show new versions available instead of saying "^1.4.1 matches 1.5, so all dependencies are up to date" without us knowing that we use an outdated version locally.

See this blog post.

Use CSP

https://github.com/rwjblue/ember-cli-content-security-policy and make sure to obey https://github.com/johnotander/ember-cli-gravatar#content-security-policy

Give all objects an id for easier testing

Check backend version

Add a file that contains the required backend version (the commit oid or the tag).
Check the version on startup and fail if the versions don't match.

See ontohub/ontohub-backend#44

User page should be visible only for admins

Add user and organization pages

For show + edit, delete.

CSRF protection

See ontohub/ontohub-backend#24.

Extend the git GUI by branches

As a follow-up on #57:

• create a branch
• delete a branch
• set the default branch

Implement the frontend part of login

Probably using https://github.com/jpadilla/ember-simple-auth-token

Build is broken

The build is currently broken because of a update to foundation. I'm currently working on it, but acoustep/ember-cli-foundation-6-sass#22 is one unresolved issue that needs to be fixed.

write a concept for the Ontohub 2.0 user interface

Focus on the overall plan.
For inspiration, have a look at http://overleaf.com (configurable tabs, file browser, version control, diff viewer), http://bioportal.bioontology.org/ (searching and browsing), http://webprotege.stanford.edu/ (configurable tabs), https://github.com (diff viewer)

Create a git branch and place your document in a folder doc. Commit and push often. Once the document is ready, create a pull request.

Add basic git GUI

Add a basic git GUI that gives the user

• a directory view
• a file view (different views for different mime-types: text, image, pdf, video?)
• a file upload into the current directory
• a way to mkdir
• file deletion
  on the default branch ('master').

Display organization's description

Should be shown on the organization's page and in the search results.

Create repository model

Remove the namespace model

In accordance to ontohub/ontohub-models#37 and ontohub/ontohub-backend#43

Try out percy

Try out https://percy.io/ to see if it can be useful for us.

Create a search result page

Frontend for ontohub/ontohub-backend#20

Create welcome view

We should have some greeter on the index page.

Registration and Deletion of Users

A GUI for ontohub/ontohub-backend#86
Let's make it a GUI for ontohub/ontohub-backend#135

Extend the git GUI by history

As a follow-up on #57, add a history (git log) page.
It should be configurable by the parameters that the GraphQL schema accepts.

Create namespace model

Create tests for repository view

See #37

Create namespace view

Should include a button to create a new repository

Use repository type images in repository creation

We're still using the mock-images on the new repository page.

Create Repository view

Should include button to delete the repository and option to edit the description.

Authorisation

React properly to authorisation failures of ontohub/ontohub-backend#87.

Infinite loop of queries

When I checkout cbcdbab844ed416a4cf9a9c23aba4b864d36f275 in the ontohub-models
and I checkout 231a1a847ef7746dbacaee533b96fab96084dc0f in gitlab_git
and I checkout 8ffc6d17fc3e5d7f364ae200b324b0a7164a72a9 in the backend
and I start the rails server
and I start the frontend server
and I visit the landing page
and I open the developer tools network tab
then I see an endless loop of graphql queries with GetVersion and CurrentUser.

This is because the backend does not respond correctly to the requests:

{"errors":[{"message":"Field 'me' doesn't exist on type 'Query'","locations":[{"line":2,"column":3}],"fields":["query CurrentUser","me"]}]}

The frontend should stop making the requests in such a case.

Use emblem.js instead of handlebars

This should make our view code more readable.

http://emblemjs.com/
https://github.com/Vestorly/ember-cli-emblem

Create components for users, organizations, repositories

Currently they are all implemented with the search-result component, which is not up to all the needs of the components. So, it's better to have separate components for each one.

Add basic repository pages

For new, show + edit, delete

Codeclimate is not set up properly

We're not generating any code climate reports.

Extend the git GUI by tags

As a follow-up on #57:

• create a tag (with an annotation)
• delete a tag
• list all tags (with their annotations)

Consider using prettier

prettier is a tool to format JS code according to some opinionated set of rules. While some of our eslint rules differ with the output of prettier, we could combine eslint with prettier, so we could easily just run eslint --fix to format the code with prettier first and then fix problems with our specific style rules.

There might be problems with conflicting rules when using the above plugin, so we should investigate this first.

Redo Mirage config from from scratch

Implementing the API when it is needed is more difficult than implementing it as soon as it's implemented in the backend. We should redo the current configuration from scratch and model the current API completely (not just the parts that we currently need in the frontend).

Possibly investigate if https://github.com/thoughtbot/ember-json-schema or https://www.npmjs.com/package/jsonapi-to-ember-mirage could be used.