Finders common fields: view reference

[ekes]

Yup, so I think in this MR or another I'd started something along those lines:

• defaults views available for a node type set in code
• admin user can edit node type config to customize / override this list
• editor user can pick from the list for a particular node

_Originally posted by @joachim-n in https://github.com/localgovdrupal/localgov_directories/issues/384#issuecomment-2421965928_

[ekes]

So only question now might be: our own field from scratch, extend Viewfield that was used on this original patch, or extend Views Reference Field that Maria pointed out we are already using elsewhere?

[ekes]

Also would keeping the semantic meaning / type of view be worth it? Then it feels more like a custom field. But maybe a delta is enough? I wonder... lists, calendars and maps; but also current and past consultations; and promoted and non-promoted news.

@joachim-n :

I wouldn't use field deltas for that use case -- too brittle. Something semantic would be better. Simplest would be just to have separate fields, one for each view.

Or -- and this might be over-engineering -- a field where we can mark each view display for its meaning.

So each value is of the form:

delta 0:
-- meaning: map
-- view_id: myview
-- view_display: map
delta 1:
-- meaning: listing
-- view_id: myview
-- view_display: listing

I suppose the advantage of that over the multiple fields method is that it's customizable per-node, and they can be reordered per-node. But I'm worried I might have reinvented Paragraphs :/

[joachim-n]

Of course the REALLY simple way to do this would be to say that if you want to show 2 views on a node, then you should build a node type with 2 views reference fields, and that way the fields each have semantic meaning.

The question with this is how likely are people to want to change a node from having one finder view to having several?

Though we do need a way to know that a view reference field is a finder view and needs things like the current node ID passing in. But that could be done in the formatter?

[willguv]

@joachim-n to review differences between the two modules above, and start making this work with Events

[rupertj]

Of course the REALLY simple way to do this would be to say that if you want to show 2 views on a node, then you should build a node type with 2 views reference fields, and that way the fields each have semantic meaning.

I like this idea. How do we know what each reference field means? Just from the fieldname?

I'm wondering if it's worth having a plugin here to let other modules define their own fields to look for, along with other data about how each view gets used. EG, we have "Main" views, which are the bulk of a channel, then an "Upper" view, like when we're showing locations with a list of them below.

[joachim-n]

I like this idea. How do we know what each reference field means? Just from the fieldname?

I was thinking either hardcoded from the name, or if we want more flexibility and extensibility, we put it in 3rd-party settings on the node type.

[ekes]

So our existing views are list and map in directories. As per https://github.com/localgovdrupal/localgov_finders/issues/1#issue-2602484670 one of those (the list) has the entity view mode updated when a new content type is added to the directory, the map doesn't (not needed). So directories needs to know about its own views to know to trigger the update on one, but not the other. Ah... but that is based on the nature of the view, you could make a title field list only view, that doesn't need updating. :exploding_head:

Still I somehow feel like the modules should define the fields and know which are their views fields, and what they use them for. But now I don't have a good argument for it :-P

[joachim-n]

Still I somehow feel like the modules should define the fields

This brings us round via another route to https://github.com/localgovdrupal/localgov_events/issues/139.

We could have a plugin type for finders, and event/directory/etc modules provide a plugin which defines the field. You create a content type, select one of the plugins, and the fields get defined on it automatically.

[ekes]

You create a content type, select one of the plugins, and the fields get defined on it automatically.

How would that work? Adding the (default) fields all in one go sounds nice, there can be quite a few of them. While they some might be optional, they are usually there, and could be removed if not required.

[joachim-n]

I was thinking we add them as bundle fields, but then they can't be removed. Bur I think that is a feature -- fields that participate in the machinery of directories shouldn't get removed by an admin accidentally clicking the wrong thing!

Are there some fields that admins would want to remove because they're not relevant to their use case?

We could have some fields get created on the fly as config like directories currently do. Or we could say that if you want to skip some fields, you should subclass the plugin.

[ekes]

Are there some fields that admins would want to remove because they're not relevant to their use case?

Primary one I can think of at the moment is the content facets field in directories, which depending on the nature of the directory you really want, or really do not want. But then it could, or maybe should, be a separate thing to add.

I was thinking we add them as bundle fields,

I have a recollection we've had some issues with bundle fields so far. With the review schedule field maybe was it? Maybe worth checking it's not a thing that could bit us. Also the API for them was never quite finished was it?

We could have a plugin type for finders

Where would the plugin be set, and what would the relationship with the bundle fields be?

[joachim-n]

I have a recollection we've had some issues with bundle fields so far

The two things I'm aware of are:

• Views support is incomplete -- they don't get declared automatically to Views data IIRC. But as we're showing finder items using SearchAPI that won't matter.
• They are missing from the field map -- see https://www.drupal.org/project/drupal/issues/3045509. Though there appears to be a workaround, which is to call fieldDefinitionListener->onFieldDefinitionCreate() -- EntityAPI does this. I don't think this affects SearchAPI either, as I can't see any calls to getFieldMap().

Though, I've had another look at how Commerce and EntityAPI do automatic fields on bundles, and their method of defining fields differs:

• EntityAPI defines bundle fields with hook_entity_bundle_field_info()
• Commerce actually creates config fields on the fly when you enable an entity trait, and locks them so they can't be changed or deleted in the UI

Where would the plugin be set, and what would the relationship with the bundle fields be?

I'm thinking the admin UI would be in the node type edit form. You'd select a plugin to make the node either a finder type, or a finder item type. A plugin like 'Events' would have methods on it that define the fields for both. Saving the node type sets the fields up.

[joachim-n]

I'm working on a prototype for this.