# 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