Closed yochannah closed 3 years ago
This equates to always accepting the "ORF" class, and focusing on subclasses of it.
We will probably need to look deeper into this to find an optimal solution.
Update: I looked deeper and this will require building a hierarchy based on the extends keys in the model. This is already done in the data browser on the querybuilder page.
(reduce (fn [h [child {:keys [extends]}]]
(reduce #(derive %1 child %2) h (map keyword extends)))
(make-hierarchy) model)
We should save this hierarchy somewhere and recompute it when changing mines, (probably compute it when fetching model and save it in app-db, making sure it's not saved to localStorage) as it will be useful for tasks related to subclasses.
To solve this issue, we would use the hierarchy to ask whether ORF isa?
Gene, where ORF can be any class from the report or results pages, and Gene can be any class specified in the tool's classes
config.
Concrete example:
YeastMine child classes for Gene are the primary way to see gene info - for example, ORFs should display gene widgets. See a screenshot of the model below - ideally all sub-classes of gene should be able to show Gene-ready widgets. This is probably true for other aspects of the model as well.