devdocs/todo.txt

@@ -20,55 +20,38 @@ MAKE DATALIST ROUTE FOR FETCHING LISTS BY KEY
 	- Accepts datalist key
 	- finds applicable AyaDataList object for the key specified (maybe keeps a static list of them rather than finding upon reflection)
 
-
 UnMock MOCK_WIDGET_DISPLAY_TEMPLATE_JSON into db with objects and with seeded data for test and or all lists
 	- One single object with all templates in JSON maybe? since there are not going to be multiple templates for same list object anyway
 		- Server can load it up and cache it like LT?
 	- Can it just make a default template if none is found?  (no they are all required)
 	- Once both lists are working:
 
+User Object datalists?
+
+DataList object naming scheme, should it be prepended to they all align well?
+
 AyaFormFieldDefinitions still has UI field datatype in it, but I don't think I'll need it so ponder this by looking at tests and client and make a decision
 	- Consider if there is some possible future use for this or YAGNI
 
-//READ THESE NOTES, IS IT ALL DONE NOW?
-		- abstract away the commonalities into other classes
-			- AyDataList containing
-				- AyaObjectFieldDefinitions
-				- SQL from query
-				- List key
-		- 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
-			- one central route would get pretty huge though, will be clearer once I abstract out the bits
-				- Maybe instead of the objectFields monolithic class I have one small class for each list and or UI editing definition that all feed into a central spot
-					- This way each type is in it's own file and cleaner?
-			- UI custom fields and shit part is kind of separate from the list stuff with only a bit of overlap, maybe they are separate objects once again and split out?
-		- INTEGRATION TEST UPDATE Update tests when appropriate (when it's working fully and not mocked)
-		- UPDATE SPEC DOCS with new format and names etc or at least remove nonsense as necessary
+
+INTEGRATION TEST UPDATE Update tests when appropriate (when it's working fully and not mocked)
+UPDATE SPEC DOCS with new format and names etc or at least remove nonsense as necessary
+
+UPDATE MANUAL API REGARDING LISTS
 
 
 
 
 
-
-CLIENT CUSTOM FIELDS CHANGE
-	- Must use numeric instead of text values now
+CLIENT PROJECT CUSTOM FIELDS CHANGE
+	- Must use numeric instead of text values now for field types
 	- Additional NUMBER is split now between integer and decimal types update control STEP value for inputs to include decimal places or none depending on type
 
 TEST CHANGES
 	- Must use numeric instead of text values now
 	- Test datatypes enum picklist 
+	- New routes for lists
+