ayanova/devdocs/todo.txt

@@ -104,56 +104,15 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
 			- But then what about hidden fields set to sort that user is not aware of and fight with the header clicks they make?
 	- Sorting
 		- V7 can sort by up to 3 columns which makes it possible to do something like sort all customers together then by date or something
-	- STUB out any other main grid list options
-		- Put in the menu options will likely need even if not coded yet.
-			- SEARCH
-		- go through cases find the new things that need to be on the menu and stub them out.
-		- Stub them out so they are there even if not functional
-		- Maybe make all stubbed things an alt colour so can tell at a glance what is outstanding.
-		- Reporting, list mass ops, go through cases look for stuff that will be required
+	
 	
 
-	- LIST TYPES USABILITY: Two kinds of mass fetch records in RAVEN
-		- 1) Reporting records
-			- Need to filter, sort and will probably pull in many different tables so would be a set of dedicated REPORTING objects for that purpose at server 
-				- Reporting objects have responsibility for showing fields available, filter etc.  Maybe the filter and report are saved together and just duped for other filter / sorts?
-					- Only if the report is lightweight enoubh
-			- Not using name display format as it's a reporting responsibility how the raw data is displayed at that point
-		- 2) Selection records (ALL THE MAIN GRIDS ARE REALLY THIS IN RAVEN AND SHOULD ONLY THINK OF IT THIS WAY IN PLANNING SO DON"T GET IN THE WEEDS WITH COLUMN SELECTION ETC)
-			- In v7 the grids did double duty but a huge waste of bandwidth to send all that data if they merely want to find Bob's Lobsters customer to open it for example
-			- USED IN 
-				- In forms in pick lists for selection
-				- In main grids also for selection and viewing and triggering reporting (but reporting uses different lists to feed to report generator)
-			- Need to filter sort and search
-			- Uses templated name display format
-				- TEMPLATES are going to be a big thing
-				- Server needs to take into account display format
-				- SPEC: this is all worked out permanently in spec doc core-display-format-template-system.txt
-		- ACTION required: 
-			- Make sure the server supports this
+
+	
 
 	- GRID TODO FOR SURE
-		
-		- DISPLAY FORMAT TEMPLATES
-			- Needs to be in place for the grid to work basically so it's a high priority now
-			- Speccd in core-display-format-template-system.txt
-		
-		- 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 
-			
-		- 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 data type for display purposes
-					- Also each column may be openable with a hyperlink so in addition to datatype needs to know what object type to open
-					- 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
 
-		- DETERMINE AND IMPLEMENT INCREASED MAXIMUM ROW COUNT ALLOWED
+		- 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?
@@ -162,8 +121,20 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
 				- 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
 
-		- SEARCH (need to be able to search from the grid for that type of object)
+	- AFTER working mocked grid
+		- DISPLAY FORMAT TEMPLATES			
+			- Speccd in core-display-format-template-system.txt
+			- Requires server work and client work
+		
+		- MODIFY WIDGET GRID DATA LIST at server to work with templates properly
+		- SEARCH UI (need to be able to search from the grid for that type of object)
+		- FILTER UI
 		- Show the total quantity of records so it's clear the user is seeing a subset, i.e. "Showing 100 records of 30,124 (filtered)" or something to that effect.
 			- For efficiency this might need to be a fuzzy number gathered periodically at the server as part of a job and put on a route?
 			- Don't want to count them every time the list is fetched....or do I?  Maybe it's pretty efficient in Postgres?
@@ -174,6 +145,7 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
 			- 
 		- Needs to remember last settings (stored centrally) like filter used, number of rows etc
 			- When user opens up AyaNova it should always look the same in each area as last time they were there
+		- Modify the grid to no longer use mock values but real ones instead and test