DataTypeClass module doesn't work with InverseProperties (and possibly elsewhere too...)

[jlayt]

Hi,

I’m using both the DataTypeClass module and the InverseProperties module together. I’m using DataTypeClass to ensure users select resources of the correct Class for certain properties (and the selection sidebar defaults to finding them), and then InverseProperties to populate the inverse property on the selected resource.

Well, I would if they worked together. Unfortunately DataTypeClass sets the data type for a property to be like ‘resource:item#vocab:Class’, but InverseProperties only recognises ‘resource’, ‘resource:item’, ‘resource:itemset’, or ‘resource:media’ as being valid data types for inversing. So any attempt to map the inverse fails.

My workaround for now is to hack InverseProperties to also accept anything starting with “resource:”, but I suspect that’s not a fix that would be accepted upstream, and not something I want to maintain a fork for.

I suspect this is also the same cause for other issues I’m spotting, like in the Admin Item Edit page any previously saved resources for Properties using DataTypeClass do not get displayed, just empty placeholders for each one, but they still save OK and appear fine on the Admin Item Show page. Another is in the select sidebar where the Quick Creation feature doesn’t work .

There’s probably a lot of places in core and in modules that are checking for resource data type where this will cause issues, so it suggests the fix should be for DataTypeClass to use the standard “resources:item” data type and enforce the Class in some other way. A fix in core would probably need a library method like isResourceDataType() that gets called everywhere instead.

I do want to keep using DataTypeClass, there’s reasons I can’t just switch to say Resource Templates instead, and am happier to maintain a fork of that, so I’m open to any suggestions for how to make that work in a way that would be compatible with core.

John.

[jimsafley]

Thanks for looking so deeply into a solution. We could add a configuration to InverseProperties where you could add to a list of resource types that the module recognizes. Something like this in module.config.php:

'inverse_properties_resource_types' => [
    'resource',
    'resource:item',
    'resource:itemset',
    'resource:media',
    'resource:item#vocab:Class', // you woudld add this one
],

Do you think something like that would work for you?

[jlayt]

Thanks John. That would fix InverseProperties, but grepping about there’s numerous other places in core and many modules that all do the same check. Patching everywhere like that seems a bit futile just to use one non-core module.

After reviewing the DataTypeClass code and looking at where and how the data type name gets used everywhere, I don’t see a clean approach to doing what I’d like using a data type. It would need to always save type as ‘resource:item’ in the value table so checking the type behaves correctly, but also somehow magically know to use DataTypeClass form everywhere else it needs to…

The natural place is probably in the AdvancedResourceTemplate module alongside the other property validation rules, I’d just been hoping for a simpler cleaner approach…

John.