Feature/upload #77
Feature/upload #77
Conversation
|
this is definitely not an absolute requirement, but would be kind of neat if not too hard to make work. I constructed a config file with no sources (and no initial maps in view, since there are no maps); the idea was that a person could just start with a blank app slate and just construct their VM313:1 Uncaught SyntaxError: Unexpected token u in JSON at position 0 |
|
test-add-data.2.txt here's something that is probably considered a bug in the current implementation. I tried adding a set of data to an existing map, and gave the features in the new dataset a different type to help distinguish the newly added from the existing features. However, the originally present features seem to then appear in the QTL tracks for both the original feature type and the new feature type, suggesting that they are somehow getting duplicated or maybe just getting multiple types associated. I know that description was probably clear as mud but try the simple test files attached here by first adding test-add-data.1.txt to a new target map set then adding the second file to that newly created target map set, then create QTL tracks for both SNP_1 and SNP_2 and see if you can reproduce what I'm trying to describe. then see if you can fix it, if you agree it is odd behavior. |
|
The first point is due to current implementation assuming there is at least one map set to build off of, as it is infinitely easier to just clone and hijack an existing dataset than it is to build one from scratch, with a little work, it should be fixable. The second, I can't replicate the behavior. Grabbed both sets of data and uploaded, which resulted in the following screencapture when adding QTL tracks:
edit: The tracks being QTL_1 pre-upload of QTL_2, QTL_2 and QTL_1 post upload from left to right. |
|
OK, trying to re-replicate I just realized that I got confused by the UI- I had earlier created a track that combined SNP_1 and SNP_2 features rather than creating separate tracks for them. sorry for the false alarm on that. Do you want to proceed with merge before addressing point 1? I can submit an enhancement request for that, it is certainly not high priority. |
|
I'll look into the first note and see if I can get a fix up tomorrow, or merge and add an enhancement request, though probably the former. |
|
OK, sounds good. |
|
An extra input box with tag-prefix would probably be easy enough to implement. Right now its just adding an "upload-" prefix to the value in feature_type_acc, which is the first spot looked for when making tags. When that title isn't there, like the the test files above, there is not tweak to the tag. (using a prefix instead of an outright replacement allows for uploaded data to be grabbed when making a qtl track of the same tag type alongside the regular data, as populating a qtl track is just based on regex-matching, without bothering to constrain a match at beginning-or-end... I consider this a feature, but it may be unwanted behavior.) |
There was a problem hiding this comment.
starting with empty config working well, thanks! A couple of little usability things for the Add Data feature:
-I accidentally added a file twice because the state of the Add Data menu isn't cleared after the last action; there might be some arguments for retaining last selection in case of error, and I can probably come up with use cases for adding the same data twice to different mapsets, but I think in terms of default behavior it's probably best not to retain the last input (except for maybe remembering the directory of the last file selection for when they go to choose a new file). let me know if you think otherwise (and this need not be a blocker)
-one thing that is a little confusing is when a remote URL is specified and the response has a little delay, the Add Maps appears as empty until the add map dialog is reopened after the request has been processed. Not sure this is worth bothering about, but I could imagine just making things block until the request has been successfully processed. Might also be good to assume that after requesting the Add Data they want to go directly to Add Maps, at least in the case where they've created a new target set. Not sure, maybe worth getting real user input on that.
anyway, looking good; feel free to merge unless you want to address any of the tweaks suggested first.
|
Added a quick tweak that should reset the state of the upload dialog to blank out when it is opened. In an ideal future, it would probably be for the best to have an "advanced" toggleable div that allows users to specify configuration options for the new data and mark how they want the view set post upload. |
Add ability to upload local/remote files to the current view.