Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISSUE-221 --- ADO Type condition plugin. #222

Merged
merged 8 commits into from
Aug 27, 2022

Conversation

patdunlavey
Copy link
Collaborator

This is a fairly simple condition plugin that permits conditioning block display and contexts on the ADO Type of the current node.

See #221

Potential changes/improvements:

  • Use a solr facet search to create the list of ADO Types for the configuration form, rather than depending on the presence of the two webform options lists.
  • Would changing to a solr search for the current node's ADO type be more performant? Or caching?
  • I didn't bother implementing javascript to display the context summary, which seems superfluous. Is that needed?

Requesting review from @aksm

@patdunlavey patdunlavey requested a review from aksm August 16, 2022 20:40
@patdunlavey patdunlavey self-assigned this Aug 16, 2022
@aksm
Copy link
Contributor

aksm commented Aug 16, 2022

@patdunlavey Thanks! Will look over first thing tomorrow.

@aksm
Copy link
Contributor

aksm commented Aug 17, 2022

Hi @patdunlavey I've begun looking at and testing this but got sidetracked. Will circle back tomorrow.

Either way it's probably best to have a second look from Diego when he gets back since my novice eye will likely miss something.

$node = $this->getContextValue('node');

// Get the ADO type from the entity.
if ($node->hasField('field_descriptive_metadata')) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@patdunlavey this here needs to change. There are archipelagos in the wild (e.g the ones using EADs) that have different field/names. The way we do this in almost every spot is using this helper methods.

An example:

 if ($sbf_fields = \Drupal::service('strawberryfield.utility')->bearsStrawberryfield($entity)) 

But a fuller example is here: (The View Mode resolver)

$ado_types = [];
if ($sbf_fields = $this->strawberryfieldUtility->bearsStrawberryfield($entity)) {
foreach ($sbf_fields as $field_name) {
/* @var \Drupal\strawberryfield\Plugin\Field\FieldType\StrawberryFieldItem $field */
$field = $entity->get($field_name);
if (!$field->isEmpty()) {
foreach ($field->getIterator() as $delta => $itemfield) {
/** @var \Drupal\strawberryfield\Plugin\Field\FieldType\StrawberryFieldItem $itemfield */
$flat_values = (array) $itemfield->provideFlatten();
if (isset($flat_values['type'])) {
$ado_types = array_merge($ado_types, (array) $flat_values['type']);
}
}
}
}
}

Which also leads to:

  • Should we be aligned with how the View Mode resolver works? Using all "type" key values found in the JSON (independent of the hierarchy).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion. I'll just "borrow" the view mode resolver code to get the type(s).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@patdunlavey thanks so much

*/
public function buildConfigurationForm(array $form, FormStateInterface $form_state) {
$type_options = [];
foreach(['schema_org_creative_works', 'schema_org_cw_collections'] as $webform_option_list_id) {
Copy link
Member

@DiegoPino DiegoPino Aug 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@patdunlavey question.

What if we make this a Textarea, like the "path" conditions work? Reason is, maybe users have more Webform options where to source the "types" from, or named differently. This of course could be also a setting provided by the Webform Strawberryfield module, since we also "sadly" do this hardcoded in AMI ... what do you think? We could also have a multi select where you choose first which webform_option (a select box) and then the type from there?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of making it a textarea field where the user in instructed to provide a comma-separated list of ADO types. Keep it simple AND fool-proof!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@patdunlavey great. Maybe even a One Per line? That way we can reuse the code that splits/cleans that up from the other conditions that do that already and will also be a "I know how/common place" moment for users already understanding the multiple paths, each one in a single line, condition that comes standard with Drupal

@DiegoPino
Copy link
Member

@patdunlavey re: performance. I think if using the suggested method if would not be too hard on the Server. Mostly because it will discard immediately any Bundle that does not carry a SBF and once you access the flatten JSON it will be either already in place (the static cache of the field will do that for you) or will provide by just accessing the data the static cache for whatever comes next (render/etc). let's give this a try, if we feel this adds a delay we can add an option to use Solr, but that requires config (like which field is holding the type values in a particular index) and might be an overkill.

@DiegoPino
Copy link
Member

@patdunlavey last request. This requires a schema YML file too. Once you are settled with how the type config/text area is going to be stored, please attach it. You can use some other condition yml file as an example to make it easier. Thanks a lot

- Changed type selection widget from checkboxes populated from hard-coded webform options lists to a simple textarea with instructions to enter one ADO type per line.
- Added option to match type values from everywhere in the metadata, not just at the top level.'
@patdunlavey
Copy link
Collaborator Author

Sorry @DiegoPino, I just saw your "last request" after I pushed up new changes.

I'm not sure I understand what you're talking about re. schema yml file. The storage scheme is exportable to a context.context.[context_name].yml file. I'm storing the ado_types as an array of strings.

@DiegoPino
Copy link
Member

DiegoPino commented Aug 22, 2022 via email

@patdunlavey
Copy link
Collaborator Author

Incidentally, this feature is one added configuration field away from being able to condition a context on the value of any field in the metadata. But I sense scope-creep!

Copy link
Member

@DiegoPino DiegoPino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also @patdunlavey regarding the schema that is missing.

Condition plugins do have one for their configurations.

See example

condition.plugin.entity_bundle:*:
  type: condition.plugin
  mapping:
    bundles:
      type: sequence
      sequence:
        type: string

And this one from a contributed module (groups)

https://www.drupal.org/files/issues/2018-12-14/group-group_type_condition_plugin_config_schema-3020554-2.patch

$entity = $this->getContextValue('node');

$ado_types = [];
if ($sbf_fields = \Drupal::service('strawberryfield.utility')->bearsStrawberryfield($entity)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@patdunlavey can you inject this service please? Since you are already using ContainerFactoryPluginInterface that would be great (sorry you know how my code reviews are... so sorry)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dang! You're going to make me learn how to program in Drupal!! Ok, I think I did this right (copying from another example in your code).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re. the configs, this seems to come for free with context plugins. When I do drush cex, I get a context.context.[context_name].yml file. Or am I misunderstanding you?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that the annotation makes the schema definition unnecessary?

@DiegoPino
Copy link
Member

Incidentally, this feature is one added configuration field away from being able to condition a context on the value of any field in the metadata. But I sense scope-creep!

Yes, was thinking what if we add a JMESPATH and then BUM! hahaha. But what if we keep an open Ticket as a secondary Condition that extends this for further down the road? I kinda like the idea. E.g only show a MAP Block, IF there are lat/longitudes

@DiegoPino
Copy link
Member

@patdunlavey you get the "saving" for free for the YML but you still need to add the definition (schema). Append it like the example (your two config entries) to https://github.com/esmero/format_strawberryfield/blob/1.0.0/config/schema/format_strawberryfield.schema.yml

…s request. I have ABSOLUTELY NO IDEA what this accomplishes or is supposed to accomplish. So maybe it does what it's supposed to?? What I can say is that it doesn't seem to break anything, at least that I could find.
@patdunlavey
Copy link
Collaborator Author

@DiegoPino I have added something to format_strawberryfield.schema.yml, but (as my commit message says), I have absolutely no idea what it's supposed to accomplish, how to tell if it's correct, etc.

label: 'ADO Type Condition'
mapping:
ado_types:
type: array
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, almost! this is like this (there is no array type)

type: sequence
sequence:
type: string

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, updated.

Copy link
Member

@DiegoPino DiegoPino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@patdunlavey ok code looks good. Let me get this for a spin and test? If all good I merge tomorrow PM. Thanks so much, also thanks for taking care of all my concerns (but I might come back if I find an issue ok?)

@DiegoPino DiegoPino changed the base branch from 1.0.0 to 1.1.0 August 24, 2022 00:56
@DiegoPino
Copy link
Member

@patdunlavey ping, sorry. Could you please clean up the unused USE statements? All the rest is ready and I would love to merge your great pull. Thanks!!

@patdunlavey
Copy link
Collaborator Author

Unused use Drupal\webform\Entity\WebformOptions; has been removed. Thanks!

@DiegoPino DiegoPino merged commit 4000321 into esmero:1.1.0 Aug 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants