I discussed #2573457: Make stopwords translatable with @eclipseGC. As i was explaining some things; he pointed out that we could use the condition system for some of the thing we currently do.

  1. The "node status" processor can easily be replace by a "entity status" condition; and it should go in the "configure the datasource" selection on the edit form.
    This plugin doesn't exist yet; but @eclipseGC suggested providing that from ctools.
  2. The bundles selection can be replace by the entity bundles condition plugin that is already in ctools
  3. The language selection; that is currently in #2256219: Allow the content entity datasource to specify which languages to handle is already in core as a condition plugin.

The advantage of using those plugins is that they are well-tested and reusable by other projects.
Another advantage is that rules will also provide extra conditions plugins, that means that we can have rules extend the search api functionality quite easily.

This would mean that we have to maintain less code. I'm not sure if this should be beta-blocker. I definitly see the advantages of this, but I'd love to further reach agreement before working it.

Comments

borisson_ created an issue. See original summary.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Component: Framework » Plugins
Status: Active » Postponed (maintainer needs more info)

Adding the status check to the datasource config instead of having a processor for it sounds sensible in any case, yes. However, it doesn't seem like content entities have a generic concept of "status" like config entities, so I'm not sure how that could work? Or still just specific to nodes (or a few other core entity types)?

However, while it's more or less the first time I look at condition plugins and it's far from clear to me what they are really doing, it seems they can't really be used to change a database/entity query, right? Just for evaluating it corresponding to the current "context" and returning whether the condition matches.
So, unless we want to throw out the rest of the performance gains we get from using a query for filtering the whole set of entities according to the datasource config, we can't use conditions. And even then we'd have to write all three mentioned plugins ourselves, as far as I can see (OK, Language might be reusable, but only if we code the integration in a specific way so it can work) – doesn't look like much of an advantage to me.

In any case, insofar as all of this would only touch plugins (the content entity datasource and, maybe, the "Node status" processor), this probably really wouldn't be a beta blocker. But, unless I'm mistaken in my assessment of condition plugins, not really worthwhile.

legolasbo’s picture

legolasbo
he/him
Primary language Dutch
Location Middelburg
commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

I am closing this issue because information was requested over a year ago, but no new information has been provided since. Please reopen this issue with the requested information if you think that this issue is still relevant.