You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is, we are passing in a contact template to the matcher.
Thus it needs to follow field definition of the contact template.
We discussed and started implemeting an approach to let a Matcher return typed data rules it offers.
Then the matcher would also need to tell us what bundles / contact types it supports... and possibly also offer a factory to provide a contact template to fill with data.
Then matchers can offer any typed data fields they want and we can pass in data...
If a matcher offers to match across multiple bundles, the contact template possibly can skip the bundle. So this might be an optional selection and the matcher needs to support enumerating both field definition for all bundles or for a specific bundle.
The text was updated successfully, but these errors were encountered:
(as a result, whoever calls the matcher doesn't need to create a contact template on its own and the calling code has no direct use of contact field definition code at all.)
The problem is, we are passing in a contact template to the matcher.
Thus it needs to follow field definition of the contact template.
We discussed and started implemeting an approach to let a Matcher return typed data rules it offers.
Then the matcher would also need to tell us what bundles / contact types it supports... and possibly also offer a factory to provide a contact template to fill with data.
Then matchers can offer any typed data fields they want and we can pass in data...
If a matcher offers to match across multiple bundles, the contact template possibly can skip the bundle. So this might be an optional selection and the matcher needs to support enumerating both field definition for all bundles or for a specific bundle.
The text was updated successfully, but these errors were encountered: