Conversation
Accept CachedVersion-derived objects rather than SHAs for versions, and remove entity arguments since these can be taken from the versions.
Take CachedVersion derived objects rather than SHAs for the versions, and stop passing entity objects - take them from the version objects.
Initial functionality - deselect / disable versions when no entity selected Also a little bit of styling for that page, and a submit button
verb makes it clearer what's happening
jonc125
left a comment
jonc125
left a comment
There was a problem hiding this comment.
This is looking good! I've played around with it live and set 4 fitting experiments running. A few ideas from that and looking at the code so far. I still need to read through the tests of forms & views.
And implement this for datasets too
|
TODO:
|
|
I've just noticed a slight oddity with the drop-downs: once you have select one model (say) you then need to select the '----' entry before you can click again to see the full list of models! |
Yeah, this arises because of the restrictions that various other fields place on one another (mostly protocols, fitting specs and datasets) - I may need to revisit the way this logic works as it's not very user friendly. |
helenst
force-pushed
the
277-run-fitting-experiment
branch
from
6a5cf4a to
e4cc33d
Compare
helenst
force-pushed
the
277-run-fitting-experiment
branch
from
e4cc33d to
2003eee
Compare
|
OK, thinking some more about how the protocols, datasets and fitting specs restrict one another: Say we select the protocol first, then that will restrict datasets and fitting specs to those connected to that protocol. If you select the protocol as above, and then select the dataset, selecting the dataset will still restrict the protocol to just the selected protocol, because the two fields mutually control one another - both get locked in to one another until you fully deselect one of them. I guess that's a side effect of having the restrictions working in both directions. It's similar for any pairing of protocol, dataset, fitting spec being I guess one answer might be to keep some sense of the order in which things should be selected - e.g. protocol -> datasets -> fitting specs - but that might be a bit restrictive for the user. Or maybe have a "clear selections" button to reset all the dropdowns (except those preselected on page load). Or perhaps the dropdowns should keep the "invalid" options for those fields, indicating that they are so, but also allowing those options to be selected, which would then trigger a reset of values in the other dropdowns. |
|
I think possibly a combination of measures? I like the idea of a 'clear selections' button that resets everything as you suggest. As for the restrictions, I think making a selection should restrict all the other drop-downs, but not the one you just selected. So e.g. selecting a protocol would leave the other options in the menu, until a dataset was then selected, since that would restrict the protocol field. Similarly if they started with choosing a dataset, the protocol menu would be restricted but not the dataset menu (until a protocol was chosen). Does that make sense? In normal use you probably wouldn't see it happening. It only gets odd really in the case where you accidentally click on the wrong entry, so you click the menu to change it and discover your choices have disappeared! |
helenst
force-pushed
the
277-run-fitting-experiment
branch
from
51805aa to
391a14b
Compare
|
@jonc125 I'm done adding to this for now so feel free to re-review :) |
|
|
||
|
|
||
| @pytest.fixture | ||
| def fits_user(logged_in_user): |
There was a problem hiding this comment.
I think this is in conftest.py now?
UI to run fitting experiments
2 participants
Addresses #277