Add data-type classes to resource property values

[allanaaa]

As per this forum post: https://forum.omeka.org/t/tables-this-is-an-answer-not-a-question/24116/6

One user wants to apply styles based on the data types of property values (NDT integers, NDT timestamps, text, URI, etc.).

I think it's always worth offering a bit more selectability for designers.

[kimisgold]

We already do this with data types offered by the core, so we should probably file issues in modules that have not provided a data type selector on the value wrapper.

[kimisgold]

It actually looks like we're not setup for data types to provide a class to the resource-values.phtml partial. I've set up a default data type class that takes the value type and formats it into a nice css selector.

[kimisgold]

Here's what it should look like in both the public and admin views, with a getty value suggest data type highlighted in the inspector. @allanaaa, could you test with any data types you can think to see if it looks as it should?

[allanaaa]

I like it - but can we send the module name as a separate class - "valuesuggest getty-cona" instead of "valuesuggest-getty-cona"? That would allow people to style more broadly.

I am also getting "valuesuggestall-rightsstatements-rightsstatements" and I'm not sure where the "all" is coming from.

[jimsafley]

I am also getting "valuesuggestall-rightsstatements-rightsstatements" and I'm not sure where the "all" is coming from.

The valuesuggestall- prefix indicates to the ValueSuggest JS that all suggestions should be loaded on one request.

[kimisgold]

I like it - but can we send the module name as a separate class - "valuesuggest getty-cona" instead of "valuesuggest-getty-cona"? That would allow people to style more broadly.

I am also getting "valuesuggestall-rightsstatements-rightsstatements" and I'm not sure where the "all" is coming from.

Currently, I'm getting .valuesuggest-getty-cona from valuesuggest:getty:cona. To what level should these values be grouped or separated out? I think I might need a better understanding of how data type names are formatted if I'm going to use them to create css selectors. Right now I've got an exception for custom vocab data types that seem to always use the format customvocab:{$id}. I currently format them as .customvocab-{$id}.

[zerocrates]

We can't assume much about the structure of data type names... they can be anything, really.

[kimisgold]

Is there a better source for constructing css classes for data types?

At least in its current state, designers could target data types associated with a module by constructing a selector like [class*="valuesuggest"], targeting classes that contain "valuesuggest".

[zerocrates]

Providing information about what module a data type came from just sort of isn't designed into the system. You could come up with ways, but I'm not sure we'd want to use them, like looking at the PHP class name or something.

[kimisgold]

I think I'm going to leave it as is for now with everything in the data type getting hyphenated to make a class.