Now that we're using Nodes instead of custom entities, _all_ Drupal content* will try to sync its RDF (and binaries?) to Fedora. As discussed on the Claw call, we want to give the site managers the ability to configure, without going into code, which bundles will get synced (e.g. islandora_basic_image) and which ones won't (e.g. basic_page).
We discussed:
Thanks for the issue @rosiel. This is an obvious improvement that folks will be expecting.
@rosiel So.... I've been doing lot of digging on this, and just about every option I can come up with falls flat on its face. You're supposed to be able to do this with Rules. It provides two conditions (Node is of Content Type AND Entity is of Bundle), yet neither appear to function. Plus they both force you to manually type everything in since RulesConditions don't use regular Condition form methods, so you're stuck with what it can generate for you based on the annotation definition. Which is pretty unhelpful.
I also checked out the 'Business Rules' module as an alternative, but that only allows rules to act upon on content type/bundle at a time, so there'd be no way to say "Sync all Content to Fedora" or "Sync just these 3 content types to Fedora".
So... yeah. It's looking like we'll need to pull away from Rules and start just using plain 'ol Events with Condition and Action plugins if we're gonna get what we want out of this. Sad times...
Speaking out of ignorance here, but maybe it would be better to filter in the event stream somewhere after Drupal, e.g. in Alpaca?
@ajs6f As long as we give folks a way to do the filtering through a UI, it's all fair game. Responding to Fedora events would certainly save us some hassle on timing issues.
Our options at this point are to do the UI in Drupal and have Alpaca request what the user has configured, or just expose a small web service in Alpaca with a configuration form.
I was thinking a small web service in Alpaca (basically just "POST your config here") with a form in Drupal. The form POSTs to Alpaca to update config (which could be useful for adjusting other stuff) and that config includes some way to define which things get synced and which don't.
Would https://www.drupal.org/project/context be another alternative here?
@ajs6f++ That sounds like the best of both worlds. Do the UI work in Drupal but dodge the web request _every time_ we want to respond to an event.
@mjordan I've been eyeballing that module for a while looking for a way to use it. It seems to be all about placing blocks in different layouts based on content type, but that's just from a cursory look I did a while ago. I'll dig deeper and see if it could be of use.
It does way more than blocks. I've extended it to understand Islandora 7.x objects, https://github.com/mjordan/islandora_context. I haven't tried out the D8 version yet but it's worth looking into.
@mjordan Wow, that seems incredibly useful for 7.x. Are conditions triggered on page load, or can they be fired for save and update events?
Where the conditions are triggered are up to you. See the .module file for examples how I trigger them within Islandora hooks (e.g., https://github.com/mjordan/islandora_context/blob/7.x/islandora_context.module#L303 and https://github.com/mjordan/islandora_context/blob/7.x/islandora_context.module#L366).
It is incredibly useful. Our most common use is to provide a custom Solr metadata display based on PID namespace. In fact we use PID namespace condition for a whole lot of things.
@mjordan Downloading d8 version again now. This goes waaaaaay beyond what I thought it could do.
Most helpful comment
@mjordan Downloading d8 version again now. This goes waaaaaay beyond what I thought it could do.