# Gann, Eliot Github Repo: https://github.com/EliotGann/RSoXS-Samples-webui ## Tell Us About… ### Your Project - Develop a front end and back end database for user samples. - back end should be based in Tiled - separate sandbox from the rsoxs raw data? - front end should be in some web based (react?) interface - upon investigation, it seems that what I want is probably a datagrid such as - example below is promising, although might be time comsuming to complete.. I have moved efforts to more clearly defining the database side of things first - Existing user sheets list samples, and their metadata, and where they exist on a "bar" - hard coded entries automatically assigned should be sample_uid, bar_uid, user_uid? - each upload should have a bar_id -> supplied by the user, and a bar_uid generated by the site - UDPATE 11/27 I'm changing the format of the sample sheet to make it more amenable to a database... I'm not sure the best way to do it right now - a bar holds many instances of samples, a sample might be moved, copied to another bar - users will want to largely work with samples on a single "bar" at a time, but also might want to copy an old sample to a new bar - by default filter by the current bar_id/uid - in bluesky, a run should copy all the metadata from a sample into the start document, or link in some useful way - linking to the sample_uid might work? - a sample should be able to relate to all of the bluesky runs that were run with that sample (backwards link from samples -> runs) - upload of a excel sheet should have a lot of error checking - I have python code that does this, it will be hard to replicate this in javascript... - I would aim for production, replacing the current spreadsheet upload/download interface through ipython that we are using at the moment - I don't think it has to be completely replaced, just another option? - Final step required would be to also upload the acquisition sheet, which linking samples to the bluesky runs required - acquisition sheet links a "coniguration", a bluesky plan, a sample, with extra field for prioritization - generally there are ~100-300 acquisitions in a sheet, with 10-100 samples - users interact with acuqisitions a lot, this is essentially the queue of what will be measured at the beamline - sorting, repeating for all samples on a bar, duplicating for slightly different configurations etc etc are all very important ### data structure (new 11/27) - bar (a single excel file with two sheets) - can be held in a single excel file (*.xlsx) - completely describes a day to a week of samples and experiments (a single physical sample bar) - components: - bar_name (from user / excel file name) - bar_id (assigned automatically? - unique identifier with version number?) - samples (sheet 1) - sample_id - bar_id - bar_name - all the sample info (~20 columns) - some columns are required, some optional (can be left blank or completely removed/hidden?), some have specific data types / formats / fixed set of choices - acquisitions (sheet 2) - sample_id - configuration - acquisition info (~10 columns) - some columns are required, some optional (can be left blank or completely removed/hidden?), some have specific data types / formats / fixed set of choices - (not in the excel file, only in python, should be in database and eventually in web interface) an image of the bar - each sample is assigned through an interactive gui to a x,y position on the image ### interactions needed (added 11/27) - load excel file / load (duplicate) bar from database (dropdown / search) - populate samples tab and acquisitions tab - allow - sample tab - fixed bar_name for whole bar (editable at top of page) and unique bar_id (not editable at top of page) - adding / removing / editing all elements of samples - duplicating samples from old bar (locked) to new bar - uploading excel sheets to add samples to bar - adding images collected at the beamline max 2 - one front one back - this doesn't need to be added now, and might fit in its own tab better, but whatever solution I pick needs to have a path forward to this. - interactively clicking on image to assign samples to positions (update the 'location') - acquisitions tab - each acquisition allows for one sample_id dropdown from sample tab - selecting multiple rows and removing / duplicating (options like repeat n times, repeat for next n samples etc) - sort by any columns - saving - upload to database (should this lock to future editing? - add unique v# to bar_id?) - reload from database - save to excel sheet ### Required Data - new excel sheet format and sample - database adding/editing/reading capability (can be local tiled instance) ### Skills, tools, & technology - how to write a simple web front end to a sample data base with some required field and essentially unlimited optional fields that users can add about the samples. - I think this can potentially be from scratch although it is still intimitating, even with the example, with a react grid of some sort, or with dash even - how to write a tiled entry editor - Dan has a solution below - ### Needs - [X] How do I upload things into Tiled? - [X] @Cameron: please follow-up with Dan Allan - [ ] What grid tool do I use? - [X] @James: put together a simple 30-min example - [ ] Search as you type. - [X] 20 columns × 100 rows - [X] Sorting; filtering - [X] Flat, non-hierarchical - [X] User-editable cells, just text changes - [X] No live updates; refresh button - [X] No auto saving - (eliot) I think I need to more fully specify all of the interactions (see new list above) before I make a decision between homebrew/existing datagrid/dash... Response from Dan: We have experimental support for data upload. There aren't strinkwrapped instructions for doing this, though it is not hard. Should we target a local setup (i.e. on your laptop) or should I deploy something for you to use? Follow-up response from Dan: Here are tested instructions for running a local Tiled server with the experimental writeable routes: https://gist.github.com/danielballan/cd787e98bd0a2821b5f71932e22e460f (eliot) - I'll look at this this week