ISSUE-361: ADO to ADO entity reference derived/nested property views filter #362
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I tried to be faster, but this is hard. Sorry
DiegoPino
added
enhancement
…load multiple I end with duplicated ID and UUID in the value array. Diego ...
Now to what gathers us here today. On exposed fill up with Entities coming from the extra Options settings listing + actually make the Query(z) ...
Basically i got the property solving for ::calculateEntityRelationsForField wrong. The right approach (which is not here yet is).. Iterate from root to leaves all property paths. IF i find an entity relationship, reset the accumulated property paths from there (basically tread the foreign relationship as one that needs to be resolved afterwards locally (new root) agains the filter value. Keep doing that. Everytime that happens, we reset again. Don't accumulate $data... only keep one around and it needs to be filled up AT the end. Once we run out of paths. - IN effect this will - Preserve directly resolvable paths (e.g field_descriptive_metadata:label or title directly -> good for comparing ADOS against each other - Provide a clean Property path in case of a complex one. e.g 0 = field_descriptive_metadata:sbf_entity_reference_ismemberof:field_descriptive_metadata:digital_object_type would be just field_descriptive_metadata:digital_object_type (this is me explaining this to myself bc it is hard... gosh... why do i code this stuff?)
path_to_resolve from data is what we want. That is all i care for.
Next steps are: - Validations - Caching for calculated paths from a entity relationship one - Actual query - Exposed Form using a Views
As requested/asked for by @alliomeria
Still, i need to optimize the Original field v/s resulting properties path mix, so i don't over evaluate the same property path against the query ADO
In webform_strawberryfield. Don't forget @DiegoPino @alliomeria (remind me?). Maybe the solution there to avoid "select referencing" webform elements (the Collection autocomplete that shows itself in the list?) would be to pass as an extra option/argument to the Autocomplete itself via webform ? the current NODE id so we can exclude it?
But i get results, comparison is working, etc. Kinda neat
Bc probably nobody other than myself will test this. We need docs too!
your form and apis together drupal ... damn.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See #361
Not ready for review yet, lot's of code to be written. It is basically a skeleton yet but with the relevant code/methods. I tried to be faster, but this is hard. SorryOk, ready for a spin.
This new Filter is named
Similar ADO Filterand can be found for any Search API driven View in the "Search" sectionIt provides a general setting + extended (optional) setting.
The extended/optional setting allows you to select a View from a list that can drive, when exposed, the selection of ADOs available. Also, a choice for passing any contextual values into this view too. Very useful to make that list act on existing filters (e.g when using this filter on a block that acts on the current ADO it is displayed).
On the main settings, It can take a list of Nodes/ADOs if not exposed. If exposed it can expose a an autocomplete or a select.
If autocomplete is selected and no View was setup on the extended (optional) settings, it will provide a generic (basically anything accessible to the user) ADO autocomplete.
If autocomplete is selected and a View was setup on the extended (optional) setting, it will provide an autocomplete driven by the view
If select was chosen, then a View is needed. If not it will just show " - ANY ". The view will be called, rendered and used as a selection
The main setting allows any field that is not full text used to compare against. The Passed (query input) Node will be resolved dynamically against the property paths, but will make it shallow. Means if the Searched against field is a nested property path consisting of one or more entity references, only the last/direct path to an entity will be resolved against the query input
The main setting also allows to set how the values are (operator) queries against each field and also between fields.
Use cases:
Todo: