admin/raven
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-22 00:11:00 +00:00
parent 594d14a62d
commit 88d66cea1d
1 changed files with 13 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
devdocs/todo.txt
View File

@@ -20,55 +20,38 @@ MAKE DATALIST ROUTE FOR FETCHING LISTS BY KEY
- Accepts datalist key - Accepts datalist key
- finds applicable AyaDataList object for the key specified (maybe keeps a static list of them rather than finding upon reflection) - 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 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 - 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? - 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) - Can it just make a default template if none is found? (no they are all required)
- Once both lists are working: - 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 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 - 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 INTEGRATION TEST UPDATE Update tests when appropriate (when it's working fully and not mocked)
- AyDataList containing UPDATE SPEC DOCS with new format and names etc or at least remove nonsense as necessary
- AyaObjectFieldDefinitions
- SQL from query UPDATE MANUAL API REGARDING LISTS
- 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
CLIENT PROJECT CUSTOM FIELDS CHANGE
CLIENT CUSTOM FIELDS CHANGE - Must use numeric instead of text values now for field types
- Must use numeric instead of text values now
- 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 - 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 TEST CHANGES
- Must use numeric instead of text values now - Must use numeric instead of text values now
- Test datatypes enum picklist - Test datatypes enum picklist
- New routes for lists