admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2020-01-09 23:21:06 +00:00
parent 1aecae26b7
commit 76c4ab9ca5
1 changed files with 16 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
ayanova/devdocs/todo.txt
View File

@@ -49,60 +49,23 @@ 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: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
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
- Check on stackoverflow probably been asked recently in modern times
- MOST RECENT NOTES: Grid looks like shit, I know it's not done yet and it's the major UI element to work on next after these details for the shell, but ... it looks like shit, consider phone first designing it
- Way too much shit, I would like to see maybe one field on a phone at most two
- On a computer I would be offended if I didn't see more columns
- So grid needs to adapt the column count to the form factor and space
- Update the grid todo below wherever it is to reflect this
- WHAT is the actual purpose of the grid lists?
- WENT THROUGH ALL CASES FOR RAVEN
- Found nothing really that requires main grids other than the most basic reasons already here like selection, search, add, report, so the grid columns in v7 are mostly for looking at them and creating filters
- SEARCH that type of object only !!!!
- Add new record of that type
- Selection of record(s) FILTERED OR ALL for reporting or mass operations
- Feeding into reports that are highly customizable and can be used to view all data in any way desired by user rather than fucking around with grid columns
- Mass operations
- in v7 could do a mass op on *all* records, but here that would mean downloading all the records into the client which could be very fucking slow or too big
- Reporting: in v7 could report against individually selected items or all
- Plugins: in v7 plugins could be enacted against individually selected from list of items or all etc
- Maybe a good middle ground to allow for more flexibility with mass ops is to allow up to large but arbitrary number to prevent an *all* option, like 1000 or 5000 or something which should be enough for almost anything to be practically done in segments
- i.e. report on all workorders for year maybe is too large but if filter by month then can print each month separately
- Reporting number of records will exactly follow grid display??
- That was easy to grasp in v7...hmm...
- CLIENT for selective ops only, for any feature that is going to commonly be required to use against *all* records it should be a defined route at the server and the server should handle it when client triggers (i.e. something like GDPR wiping of all client data etc)
- GRID TODO FOR SURE
- 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
- 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
- This will be helpful also down the road for reporting stuff when that comes up as a source of copy-pasta
- 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
- 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
- This will be helpful also down the road for reporting stuff when that comes up as a source of copy-pasta
- 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
- AFTER working mocked grid
- DISPLAY FORMAT TEMPLATES