Proposal - add support for defining 'fields' within json blobs
This covers a discussion at https://chat.civicrm.org/civicrm/pl/pt4nizctz7db8xecrq1triy38e
whereby we have a few entities with configuration options that can't be adequately captured in fields. We sort of make this work with payment_processor by having fields that we kinda rename via the payment_processor_type table and as long as there are only 4 fields it's fine. However, it's not a great structure.
I'm working on a monolog extension and like payment processor and geocoders the configuration options desired by the service varies - but it's not 100% open ended - ie we don't want to just pass through 'whatever'. The best data model to store this is a json blob- however, we then have no UI knowledge of what would go in there and afform is unable to present this field in a UI-friendly way
We looked at the idea of having something like
<field>
<name>contact_type</name>
</field>
<field>
<name>contact_sub_type</name>
</field>
<field>
<name>options</name>
<type>text</type>
<serialize>json</serialize>
<schema-callback>CRM_My_Schema::getFields</schema-callback>
<schema-watch>contact_type,contact_sub_type</schema-watch>
</field>
Where the UI layer would need to implement the ability to watch the fields defined as schema-watch and update the UI based on it (presumably only for fields that are ALSO already displayed)
A simple xml definition of subfields might look like https://gist.github.com/totten/84c140310d4adc9b5d3842b5d3364a9e - which could be rendered by a generic function.
@totten @seamuslee - anything else you think is important to transfer over here?