From 88d66cea1d462a0813617b56498a256aef4c4552 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Wed, 22 Jan 2020 00:11:00 +0000 Subject: [PATCH] --- devdocs/todo.txt | 43 +++++++++++++------------------------------ 1 file changed, 13 insertions(+), 30 deletions(-) diff --git a/devdocs/todo.txt b/devdocs/todo.txt index dee395b6..5efd478a 100644 --- a/devdocs/todo.txt +++ b/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 +