This commit is contained in:
@@ -45,6 +45,13 @@ CURRENT ROADMAP
|
||||
CURRENT TODOs
|
||||
=-=-=-=-=-=-=
|
||||
|
||||
|
||||
TODO: Make sure can easily make new record in Widget form before getting into deeper stuff or making any other object forms.
|
||||
|
||||
TODO: UI would be greatly enhanced if server defined form customization rules for required fields both Custom and regular were incorporated into client end before roundtripping to the server
|
||||
- Right now it has to save the record to get the return errors about required fields, that is shit. The client is easily able to tell what is required in the form customization so it should be able to surface that up front
|
||||
- This will save bandwidth and annoyance factor 1000 for people
|
||||
|
||||
TODO: Widget edit form, new record sb time and dates pre-filled in? Server involved? How to handle new record initial date set?
|
||||
- Seeing a few issues that are probably related to having an empty record on start of new object
|
||||
- Don't start blank basically
|
||||
@@ -54,16 +61,37 @@ TODO: Widget edit form, new record sb time and dates pre-filled in? Server invol
|
||||
TODO: Widget edit form, new record cdata error as it's empty on new
|
||||
- To see, create new and edit the custom2
|
||||
|
||||
TODO: Custom fields
|
||||
- Needs to cache the customization data of the form and concurrency token used to fetch it and then it checks the concurrency token periodically
|
||||
- {"data":{"id":1,"concurrencyToken":3761005,"formKey":"widget","template":"[{\"fld\":\"WidgetNotes\",\"required\":\"true\"},{\"fld\":\"WidgetCustom1\",\"hide\":\"false\",\"required\":\"false\",\"type\":\"datetime\"},{\"fld\":\"WidgetCustom2\",\"hide\":\"false\",\"required\":\"true\",\"type\":\"text\"},{\"fld\":\"WidgetCustom3\",\"hide\":\"false\",\"required\":\"false\",\"type\":\"number\"},{\"fld\":\"WidgetCustom4\",\"hide\":\"false\",\"required\":\"false\",\"type\":\"bool\"},{\"fld\":\"WidgetCustom5\",\"hide\":\"false\",\"required\":\"false\",\"type\":\"currency\"},{\"fld\":\"WidgetCustom6\",\"hide\":\"false\",\"required\":\"false\",\"type\":\"date\"},{\"fld\":\"WidgetCustom7\",\"hide\":\"false\",\"required\":\"false\",\"type\":\"time\"}]"}}
|
||||
|
||||
- Needs to be aware of and handle the fact that the end user may change the data type
|
||||
- if it expects a type of value and finds one it can't co-erce into the new type then it should zap it or set it null by default.
|
||||
- This could get ugly so just stick to a simple system like wiping uncoercable data and fuck it, they made their choice :)
|
||||
- Implement then Componentize
|
||||
- Maybe start with a component first now that I have my feet wet in it, saves time
|
||||
- Have to think about the design, but probably most useful when on the same page as the main record just like in v7 windows
|
||||
- Should be a single component I can reference on the form that handles it all directly
|
||||
- Custom field "slot" maybe just like the VUE Way so that it can be easily optionally shown or not in it's slot
|
||||
- Though, these need to be part of the record as well, hmmm...maybe better if they appear to be just normal fields and are added dynamically??
|
||||
- It would be nice though to just insert a slot and let a component handle it rather than buncvh of code on every form...
|
||||
- It's kind of like one control that is bound to the JSON custom fields-field and it would update it as edited and required so I guess this is how to think about it and implement it, as a control
|
||||
|
||||
TODO: Form customize UI
|
||||
- Where you create custom fields and edit
|
||||
- If a user changes a field data type there needs to be a big warning before accepting it.
|
||||
|
||||
TODO: Support form customization beyond Custom:
|
||||
- hide fields not used
|
||||
- force user to enter a value in a field optionally that isn't already required
|
||||
|
||||
TODO: Save button isn't enabling on changes in new record when it should. Enter in a value in the Name field of an empty record and move to a new field and it should immediately show the save button due to dirtiness?
|
||||
- Or is it becuase of broken rules that are not being displayed immediately? (new record should really show a bunch of broken rules right away as it has some empty and required fields)
|
||||
- Yes this seems to be it, also until all rules are unbroken save sb not enabled, but it appears that one more edit needs to be done after the last broken rule to unstick it or maybe it's the case mismatch issue above that will fix it
|
||||
|
||||
TODO: Make sure can easily make new record in Widget form before getting into deeper stuff or making any other object forms.
|
||||
|
||||
TODO: UI would be greatly enhanced if server defined form customization rules for required fields both Custom and regular were incorporated into client end before roundtripping to the server
|
||||
- Right now it has to save the record to get the return errors about required fields, that is shit. The client is easily able to tell what is required in the form customization so it should be able to surface that up front
|
||||
- This will save bandwidth and annoyance factor 1000 for people
|
||||
|
||||
|
||||
|
||||
TODO: Bug? Set widget edit form times to 4:20pm and observe that in the main grid list it shows as 320 pm!?
|
||||
|
||||
@@ -100,27 +128,7 @@ TODO: (may be done already) modify the inventory-widget-edit form initialization
|
||||
TODO: DataDump plugin needs an explanation of what it is in the flow, right now it's completely cryptic and people may be using it for stuff thinking it's for something it's not
|
||||
- Also, verify it's manager account only that can run it or maybe someone with total rights to everything?
|
||||
|
||||
TODO: Custom fields
|
||||
- Needs to cache the customization data of the form and concurrency token used to fetch it and then it checks the concurrency token periodically
|
||||
- Needs to be aware of and handle the fact that the end user may change the data type
|
||||
- if it expects a type of value and finds one it can't co-erce into the new type then it should zap it or set it null by default.
|
||||
- This could get ugly so just stick to a simple system like wiping uncoercable data and fuck it, they made their choice :)
|
||||
- Implement then Componentize
|
||||
- Maybe start with a component first now that I have my feet wet in it, saves time
|
||||
- Have to think about the design, but probably most useful when on the same page as the main record just like in v7 windows
|
||||
- Should be a single component I can reference on the form that handles it all directly
|
||||
- Custom field "slot" maybe just like the VUE Way so that it can be easily optionally shown or not in it's slot
|
||||
- Though, these need to be part of the record as well, hmmm...maybe better if they appear to be just normal fields and are added dynamically??
|
||||
- It would be nice though to just insert a slot and let a component handle it rather than buncvh of code on every form...
|
||||
- It's kind of like one control that is bound to the JSON custom fields-field and it would update it as edited and required so I guess this is how to think about it and implement it, as a control
|
||||
|
||||
TODO: Form customize UI
|
||||
- Where you create custom fields and edit
|
||||
- If a user changes a field data type there needs to be a big warning before accepting it.
|
||||
|
||||
TODO: Support form customization beyond Custom:
|
||||
- hide fields not used
|
||||
- force user to enter a value in a field optionally that isn't already required
|
||||
|
||||
|
||||
TODO: Record history display / check other AyaNova 7 options / buttons that need to carry forward
|
||||
|
||||
Reference in New Issue
Block a user