Couple context conditions

[mjordan]

Over the holidays I created two Context conditions, one that determines if a node has members and one that checks the (7.x) namespace in a CLAW object's migrated PID field.

I'd appreciate hearing if anyone would find either of these useful. If so, I'd be happy to open PRs to add them to the core Islandora module.

[seth-shaw-unlv]

I'm curious as to the need for the node has members condition. Views already has a setting to hide a block if there are no results (e.g. the node has no members) in the "Advanced" section: "Hide block if the view output is empty: Yes."

Or would we use the condition to control a viewing mode?

[mjordan]

@seth-shaw-unlv thanks, I was unaware of that. If using Views' built-in setting hides the block that would list members is sufficient, then having that as a separate condition wouldn't add anything.

Can you give an example of a different view mode that we might implement using this condition? E.g., maybe a book would have a different mode than a simple two-child compound object?

[mjordan]

Sorry, I wasn't very clear in my last question. The specific difference would be a different view mode for a simple compound object and a book, initiated with a two-condition context where the node had a tag "book" and it had members. If Views' built-in option plus the "has tag book" condition are still fine in this case, then the separate "has members" condition would still be redundant I guess.

[seth-shaw-unlv]

I would probably do this as a one-two punch. I would add a "book" tag to the display hints taxonomy (ala Open SeaDragon) to control the view mode (which of the node's fields gets displayed with which formatters) and then set the member's block visibility based on the presence/absence of members.

I guess the only reason why you would want the Context condition is if you wanted display/hide specific fields for a node only if it had members and was tagged book. But what field's visibility would you want contingent on that? I guess I would just have to see it in use.

All that stated, block placement should be able to make use of the "has taxonomy term condition" provided by islandora, but I don't see it available. True, I can set it in Contexts, but I would rather use the block placement UI. I wonder what is going on there...

[mjordan]

I was surprised to see that Conditions now (in D8) show up in block visibility settings as per (my quick reading of) https://www.drupal.org/node/2287827. Not sure why "has taxonomy term condition" doesn't show up though.

[dannylamb]

@mjordan We very purposefully alter it out of the form. Our conditions were causing issues with core block placement. See 9fb4702

[dannylamb]

@seth-shaw-unlv ^^

[mjordan]

Thanks, didn't see that.

[seth-shaw-unlv]

@dannylamb does that mean we should add exclusions for my recent entity_bundle condition in islandora_form_block_form_alter?

[dannylamb]

@seth-shaw-unlv yeah let's do that

[seth-shaw-unlv]

Actually, @dannylamb, let's leave the entity_bundle condition enabled for block placement... It doesn't break block placement and it would be useful for placing blocks on taxonomy term pages (e.g. showing repository items tagged with that term).

[mjordan]

I'll let discussion on the NodeHasMembers condition continue, but as for the NodeHadNamespace condition, I'm wondering if @rosiel has an opinion since she created the use case that motivated me to write it. While the condition doesn't simulate Fedora 3.x-style namespacing in Fedora 5, it might let us simulate the user-facing functionality of Islandora 7.x namespaces in a CLAW instance migrated from 7.x.

[mjordan]

Condition to test PID namespace added with #147.