Implemented Imagery selection screen #236
Implemented Imagery selection screen #236
Conversation
6326900
to
91e648c
Compare
interface/backend/api/views.py
Outdated
return Response({'response': "An error occurred: {}".format(e)}, 500) | ||
|
||
# drop existing case(s) with candidates and nodules | ||
all_cases = Case.objects.all() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hang on, is that right? It will essentially make the entire process global whilst we would surely want it per-client?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a valid concern, but it's a way all our modules implemented right now. We can later add authentication and implement per-client separation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lamby Bear in mind the design doc stipulates single standalone computer w/ no auth story to keep everyone focused on the value added parts of the project.
interface/backend/api/views.py
Outdated
|
||
# drop imported images | ||
all_images = ImageSeries.objects.all() | ||
all_images.delete() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI you can can do ImageSeries.objects.all().delete()
</div> | ||
</div> | ||
<p> | ||
You can select an other DICOM image and start a new case |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
an other
-> another
this.preview.paths = paths | ||
}) | ||
|
||
EventBus.$on('start-new-case', (filePath) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder why is this using EventBus? The method to send new case can be invoked from startNewCase directly. If the params filePath is missing, we can simply pass it into this ImageSeries component via the props down in the TreeViews.
I think we should use EventBus sparingly to ensure components are modular and feature-compact. (That is, if I take this component and use it somewhere else, I would want to depend on this component to handle the job without having to worry about emitting an event from the parent component)
My suggestion is to move the Button from the TreeViews into the ImageSeries component and bind the onclick event locally in the image series.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@louisgv, I am new to Vue.js so may be wrong but it seems like there is no simple way to implement two way binding between one component and it's ground child. We can emit events and catch+emit them on each middleman, but it doesn't seem nice to me. Also we can use DOM method this.$el.dispatchEvent
like suggested here. But it's not nice neither.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Serhiy-Shekhovtsov I think I should have commented on the function down there instead of here :p
My thought was, is there a way to make the grand-child component feature complete without the need to rely on the grand-parent component? Since if the grand-child needs anything, the grand-parent can simply pass it down. Thus, we can maintain the uni-directional data flow, and will not have to worry about propagating data upstream, and will also ensure the grand-child has all the feature it need to be stand-alone and re-usable.
91e648c
to
df889ae
Compare
@Serhiy-Shekhovtsov @vessemer I see that this also part of PR #233. How might we best come to a consensus on which to merge..? Or which bits to merge, etc.? |
@lamby my PR fits with requirements and easier for user: you can see images on the local system by default, click Preview and click Start new case. From my point of view, those steps are redundant and don't match with requirements. Of course, @vessemer can still update his PR, but I can't see much sense in this. If points is an issue - I have no problem with sharing them between us. |
@Serhiy-Shekhovtsov, in your PR I'm mainly concern with the |
I think this is needed.. or, putting it another way, I could open another issue to do this separate to this. Let me know :) |
Switching between cases is good idea. From my point of view, the following changes could improve the #233: No need to show Import button and require user to click itShow the list of cases and the TreeView with files by default. User should be able to switch the case or start a new case with minimum amount of clicks. No need to require user to import image before starting a new caseNor to show the redundant information. On the backend you can use Accordion like behavior for files TreeViewBecause user should see what file he is previewing now. In current version user can unfold multiple folders same time and it's not clear what DICOM is opened in the viewer at the moment. This is the reason I used If these changes are OK with you guys, @vessemer can update his PR and I will close my in favor of it. Alternatively, I can merge the list of cases from #233 to my PR. |
To clarify, it isn't really switching between cases it just that the system surely needs to be able to support multiple cases happening independently of each other.. I mean, otherwise we just have introduced a bunch of global variables / state that, well, that hopefully speaks for itself :) I'd really dearly love for us to get one of #236 or #233 merged and am very happy to award points to both, I'd just need some clarification/confirmation on what exactly what code we should end up. Did you come to any conclusions on this on another ticket? :) Let me know and I'll "action" stuff ASAP. |
I've implemented the aforementioned features without additional |
Loving the GIF screenshots btw - keep them coming! So, I'm seeing some conflicts here (and on #233 FYI). @Serhiy-Shekhovtsov Any input from thee? :) |
Guys, I am closing this PR in favor of #233. Will post my thoughts there. |
Description
According to documentation on this screen should in particular:
All these features has been implemented in this PR(frontend and backend).
Reference to official issue
Related to #145 and #202
CLA