devdocs/todo.txt

@@ -18,13 +18,17 @@ GRID LISTS TODO NOW:
 		- Can it just make a default template if none is found?  (no they are all required)
 	- Once both lists are working:
 		- abstract away the commonalities into other classes
-		- REFACTOR: There's going to be a fair number of data source lists in routes so..
-			- NOT immediate issue, but once the lists are working...
+		- REFACTOR: There's going to be a fair number of data source lists in routes so..			
 			- Do I make a route for each one or user provides a key of which list they want and that goes into a single route to return the data?
 			- What about when there are dozens of reports, do they all hang off each object type controller or is there just a central data list route for all combined?
 				- i.e. if I want to make a widget->user->Email report and a separate user email report are they each in widget and user
 				- Or, because they are read only lists used for many things do they just go into a central route for read only lists?
+				- I LIKE CENTRAL BECAUSE IT"S TASK ORIENTED and will mean the object controllers can focus on CRUD stuff
 				- Also rights issues might affect this..?
+				- MAYBE it should be a single class object per list with defined properties based on an abstract LIST_DEFINITION class
+					- Can store rights, field names, sql from etc etc, making the actual list route code maybe into a single controller and single route working off keyed names					
+					- Then they can all go in a single folder for all report lists etc and can just crank out more as required over the years
+					- With a single class that contains only the names of the keys for fetching with descriptions and object types etc so can fetch by object type or whatever
 			- One central route with keys would simplify the client end UI certainly
 			- Maybe all WidgetController routes are only for CRUD (and mass change) ops and not for list retrieval?
 				- Would simplify the WidgetController and biz for sure