Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON config file for mines to add extra filters #57

Closed
AdrianBZG opened this Issue Jul 18, 2018 · 6 comments

Comments

Projects
None yet
2 participants
@AdrianBZG
Copy link
Owner

AdrianBZG commented Jul 18, 2018

JSON config having the name of each mine, its service API and the filters its able to handle.

@yochannah

This comment has been minimized.

Copy link
Collaborator

yochannah commented Jul 18, 2018

will this approach still allow new mines added to the registry to be viewed automatically in the tool?

@AdrianBZG

This comment has been minimized.

Copy link
Owner Author

AdrianBZG commented Jul 18, 2018

@yochannah Not really, since you need to hardcode each mine in that JSON file, and say which of the filters currently available in the browser its able to handle (by looking manually on the ontology concepts of that mine)... is this bad?

@yochannah

This comment has been minimized.

Copy link
Collaborator

yochannah commented Jul 18, 2018

We'd like to have it respond to new mines in the registry as the registry gets updated - otherwise there's a bit too much risk of this tool getting out of date.

A config file containing the URL of the mine is fine, so long as:

  • we have defaults for mines that don't have configs and/or
  • we access the still-to-be-made API endpoint that provides these configs.

Does that sound ok?

Also, once you've defined roughly what the config json should be like let me know and I'll make the ticket on InterMine to turn it into an API endpoint.

@AdrianBZG

This comment has been minimized.

Copy link
Owner Author

AdrianBZG commented Jul 18, 2018

@yochannah What about this?:

  1. JSON config file defining mines and available filters, for those mines that can handle more filters than the 4 general default ones, so that filters are added to the sidebar dinamically.
  2. Fetch all mines from the registry, and for those mines that are not defined in the JSON file, only show the default 4 filters.

This way we have the possibility to work with all the new mines in the registry, and for those ones that some extra filters are working due to the ontology, we can define them so the filters are available.

How this sounds to you?

I'll tell you later what kind of constraints, in terms of concepts existing in the ontology, a mine should pass in order to handle each of the filters, so that the API endpoint can return that.

@yochannah

This comment has been minimized.

Copy link
Collaborator

yochannah commented Jul 18, 2018

ok yes, that sounds like a good approach!

@AdrianBZG AdrianBZG changed the title JSON config file for mines to be shown in the switch JSON config file for mines to add extra filters Jul 18, 2018

AdrianBZG added a commit that referenced this issue Jul 19, 2018

AdrianBZG added a commit that referenced this issue Jul 19, 2018

AdrianBZG added a commit that referenced this issue Jul 19, 2018

@AdrianBZG

This comment has been minimized.

Copy link
Owner Author

AdrianBZG commented Jul 19, 2018

@AdrianBZG AdrianBZG closed this Jul 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.