Files
raven/devdocs/specs/core-main-grids.txt
2020-01-09 20:42:26 +00:00

60 lines
3.6 KiB
Plaintext

MAIN GRID SPECS
OVERVIEW
Main grids show all the stuff people have entered in Raven and are used for selection to edit/ view, filter and sort for reporting and mass operations.
Proposed system is a hybrid grid system that has two modes to take into account the width of the display device:
- Xtra Small (XS ) < 600 pixels wide (my phone is 393px)
- In this mode only one column shows and it's formatted according to the Display Format Template
- DisplayFormatTemplate is specd in the core-display-format-template-system.txt doc
- So the user chooses which columns to show in a small factor themselves, default is name only or equivalent
CASES
None that are intrinsically grid related really, just 3 or so regarding specfic fields to add to grids
REQUIREMENTS
Client
- Client needs to tell the server which form of list is required, i.e. it's client window size when fetching a list
- HYBRID BIMODAL: XS or LARGE (for now but consider maybe a medium down the road in planning)
- in XS mode
- the client sends "viewport=xs" to the client with the grid data request
- Client receives two field list back (id and display field), displays the single field
- in large mode
- the client sends no viewport= parameter as it's optional and understood to be full size
- the list comes back as an object with not only the actual columns but also a separate property listing the set of columns in order to be displayed
- Also their data type
- Also need what type of object if openable with an url
- Client expects an arbitrary set of columns in an arbitrary order defined by server so doesn't have a pre-ordained set of things.
- HMMM... Maybe I only need a single list object that adapts to the data being sent back!!!!!
Server
- Server needs to accept a parameter from the client when a grid list is fetched that tells it if it needs to send a single column templated list
- viewport="XS" I think would be sufficient
- Grid lists need to know what their template is as more than one list might use the same template?
- SERVER SENDS LIST OF COLUMNS
- The server needs to tell the client which columns are coming back with the list and what types etc so the client can just adapt to any template setting
- column list has type of object behind each column if applicable so client can make hyperlinks
- SERVER SENDS DATA
- Data in json format
- Each row has each column as a object comprising of:
- Display value (the data to show, not formatted yet, that's up to the client)
- Optional: ID value (if the object is openable then this is the id to open for the client to put a hyperlink on that column)
- For example (wide list):
data:{
columns:{ {name:"lt_client_name",datatype:text,ayatype:client},{name:"lt_client_notes",datatype:text},{name:"lt_last_workorder",datatype:number,ayatype:workorder}}
rows:{ {display:"Green mechanics",id:32},"...notes...",{display:"42",id:42}, ...thousands more etc.... }
}
- For example (XS list)
data:{
columns:{ {name:"lt_client",datatype:text,ayatype:client}}
rows:{ {display:"Green mechanics",id:32}, ...thousands more etc.... }
}
- has separate property defining all columns in list, their datatype and ayatype if openable
Back AND front end