NPLinker / nplinker-webapp

Apache License 2.0
2 stars 2 forks source link

Add checkboxgroups for tables columns #3

Closed gcroci2 closed 1 month ago

gcroci2 commented 2 years ago

image

Now the user has the option of selecting which columns to display, starting with only two of them for each table.

Some questions:

gcroci2 commented 2 years ago

Also, for checking style with prospector, we should open a separate issue for fixing all the errors first. What priority does this have?

andrewramsay commented 2 years ago

For example, I think Spectrum ID is redundant (we already have ID) but I am not 100% sure.

If you want to reduce the number of columns I would remove the "ID"'s rather than the "object_type ID" columns. The "ID" columns just show the index of each object in the internal lists that NPLinker constructs when loading a dataset, I don't think they're relevant for webapp users. I think I just added them in originally in case they might be useful somehow (and they did help debugging at times) but I don't think they have to be shown in the UI.

The "object_type ID" columns are more useful because for most types you can use them to lookup specific objects with the API, e.g.:

npl = NPLinker(...)
...
gcf = npl.lookup_gcf(123) # get GCF with GCF ID 123
spec = npl.lookup_spec(456) # get Spectrum with Spec ID 456

So if you're working with the webapp and find some interesting objects and then want to use the API to explore further you can just copy the IDs and retrieve the same objects that way.

gcroci2 commented 2 years ago

For example, I think Spectrum ID is redundant (we already have ID) but I am not 100% sure.

If you want to reduce the number of columns I would remove the "ID"'s rather than the "object_type ID" columns. The "ID" columns just show the index of each object in the internal lists that NPLinker constructs when loading a dataset, I don't think they're relevant for webapp users. I think I just added them in originally in case they might be useful somehow (and they did help debugging at times) but I don't think they have to be shown in the UI.

The "object_type ID" columns are more useful because for most types you can use them to lookup specific objects with the API, e.g.:

npl = NPLinker(...)
...
gcf = npl.lookup_gcf(123) # get GCF with GCF ID 123
spec = npl.lookup_spec(456) # get Spectrum with Spec ID 456

So if you're working with the webapp and find some interesting objects and then want to use the API to explore further you can just copy the IDs and retrieve the same objects that way.

Thanks Andrew, I removed the IDs column in all tables.

image

What about the Metcalf score column? I see that it's always -, at least for this dataset (root = "platform:MSV000079284")

andrewramsay commented 2 years ago

What about the Metcalf score column? I see that it's always -, at least for this dataset (root = "platform:MSV000079284")

That column is only supposed to update with actual values when you select some objects and run Metcalf scoring, displaying the scores for the target objects.

I'm not sure if it makes sense to keep it there because it obviously only works for Metcalf and not any of the other scoring methods that already exist and might be added later, and you are already able to view the full scores below the tables. It was maybe something we added to see if it was useful, I can't really remember.

If you want to remove the column these are the points where I think it is currently getting populated:

https://github.com/NPLinker/nplinker-webapp/blob/fdc4cd9c7729c2170ae6d97b3850443b2edbf8a9/nplinker/main.py#L1109 https://github.com/NPLinker/nplinker-webapp/blob/fdc4cd9c7729c2170ae6d97b3850443b2edbf8a9/nplinker/main.py#L1253

gcroci2 commented 1 month ago

We are implementing a new dashboard from scratch, so this PR won't be merged anymore.