This commit is contained in:
2020-01-10 00:04:23 +00:00
parent 45cac0c79b
commit 41611ac40b

View File

@@ -47,24 +47,7 @@ CURRENT TODOs
SHELL / NAV / MENUS / LAYOUT
TODO: Read through grid item below, cogitate then make todo's with actual planned changes that must happen to implement, then whack them off one by one ;)
TODO: GRIDS
- RESEARCH MAX ROW COUNT?
- Changes required at server and client (need more options at client for selection in drop down max rows thingie)
- Also docs for api need changing
- In light of mass ops above what is the best practical limit to number of rows to bring down?
- I'm thinking some people are sitting on the local network with the server and don't have an issue with a huge amount of data coming down the pipes
- Determine a sane maximum and implement it
- See what other commonly used api's are doing out there
- SharePoint 2013 max 5k records
- Salesforce 2k
- Wordpress 100
- Azure app insights 10k
- github search api max 100
- Check on stackoverflow probably been asked recently in modern times
- MAKE GRID AS GENERIC VUE COMPONENT
- Make the grid itself as a generic component that handles the most essential parts common to all forms
- This way can plunk it in different list forms and then wrap it with what is unique to that form and type etc
@@ -72,6 +55,8 @@ TODO: GRIDS
- USE MOCK column definition at the server end for now so can do client dev right up to functioning grid *then* go back and do the server template and column definition stuff for real
- MUST HANDLE HIDDEN FIELDS AND NOT DISPLAY (this is also a server issue)
- Grid does *NOT* have sort indicators or controls, that's behind the grid in the filter UI, this is necessary for reasons I forget
- Max 100 rows in grid at a time with paging
- AFTER working mocked grid
- DISPLAY FORMAT TEMPLATES
@@ -94,7 +79,7 @@ TODO: GRIDS
- Modify the grid to no longer use mock values but real ones instead and test
TODO: Client API code handle
TODO: Make errorBoxError message box on all forms a component instead as it's just boilerplate