Field Type Registry: Share custom types across instances#34
Merged
Conversation
zinigor
requested changes
May 25, 2026
Contributor
zinigor
left a comment
There was a problem hiding this comment.
Yeah, I can see how the doc is not describing the functionality well. I really like your suggestion about making an optional registry parameter. It seems that currently the DataView is meant to work as a single top level instance, and I really like the dependency injection-ish approach that this allows us to use in the future. I think it would be enough, because everything else DataView initializes in the constructor seems to be reusable and depends on the registry and the passed configuration.
Contributor
Author
|
Alright! I updated the PR, we should now be able to define a custom $registry = new FieldTypeRegistry();
$registry->register_type( 'phone', [...] );
$view = new DataView(
[ 'fields' => [ 'phone' => 'phone' ], ... ],
$registry
); |
zinigor
previously approved these changes
May 27, 2026
Contributor
zinigor
left a comment
There was a problem hiding this comment.
Nice, let's go with this approach!
…or previous approach)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi @zinigor!
I believe there is a small issue with the custom field types registration currently
According to this example from the documentation,
FieldTypeRegistryinstances should share custom types:However, it does not seem to be the case currently as each instance hold its own types (here)
This behavior prevents the use of custom fields, as
DataViewinstantiate its ownFieldTypeRegistryinstance (here, inside the constructor) which will trigger a fatal error when reaching this part if a field type is not registeredI switched types to a static attribute, as it seems to be the expected behavior and was the easiest way to fix the issue without introducing syntax changes
If you don't want to change
FieldTypeRegistry, I can also change this PR to pass aFieldTypeRegistryinstance as a second (and optional) parameter ofDataView: