While working on a patch for the Collections module, I could notice there's not currently a way to get the data that was passed to the override, e.g. the collection that was chosen in SPS.

Patch comming soon.

CommentFileSizeAuthor
#1 sps-access-to-override-data-2057223-1.patch5.3 KBrecidive
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

recidive’s picture

recidive CreditAttribution: recidive commented
Status: Active » Needs review
FileSize
sps-access-to-override-data-2057223-1.patch5.3 KB

This is useful for modules that want to do something with data, so they can call something like that and have access to the "conditions data" that was passed to the Override for generating overrides:

$override_data = sps_get_manager()->getSiteState()->getCondition()->getOverride()->getData();

Attached is a patch that adds a getData() method to the OverrideInterface and also does some cleanup on some Override implementations relying on an abstracted implementation of setData() and getData() methods.

indytechcook’s picture

indytechcook CreditAttribution: indytechcook commented
Status: Needs review » Needs work

This is interesting. I feel like there is an easier way to do this but I can't seem to remember how.

I"m changing the status to see if I can trigger the test bot.

indytechcook’s picture

indytechcook CreditAttribution: indytechcook commented
Status: Needs work » Needs review

Setting back for testbot.

indytechcook’s picture

indytechcook CreditAttribution: indytechcook commented
Status: Needs review » Needs work

I see you know what you are doing by this patch and the last one. I don't like pulling this data form the overrides though. The data property on the override is so inconsistent. For example, it could return an string as in the Collection Override or could be an array of overrides like the AggregatorOverride which is the default override you get at sps_get_manager()->getSiteState()->getCondition()->getOverride().

I agree that access to this data can be useful but I think it belongs in the condition and not the override. The override shouldn't really be relied upon to store anything non-mutable. By nature, overrides change information. That's the purpose of them.

I am in favor of putting something on the Drupal\sps\Plugins\Condition\WrapperCondition that returns what was set on the form. The object is already storing the form_state so it's accessible. This would probably be best delegated to the BasicCondition and do something similar to what submitElement() does in getting the values that will be passed to the override.