#996 - Allow catalogue embedding blocks to perform reverse-lookups on linked data
-
By Robbie Goacher
- Added
- 2 views
| Identifier | #996 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Allow catalogue embedding blocks to perform reverse-lookups on linked data |
| Status | Completed |
| Handling member | Chris Graham |
| Addon | catalogues |
| Description | Allow blocks to perform a reverse-lookup on data that's linked together via the catalogue system.
Let's say I have a catalogue of locations, and a catalogue of events, I can use the catalogues system to link each event with a location. While I can use an embedding block to display a list of all the locations, I cannot use a block to display a list of all the locations that a particular event is held at. A reverse-lookup system would solve this issue. |
| Steps to reproduce | |
| Additional information | Suggested implementation:
New syntax like: 2.c_name=events,2.id=3,[email protected] Which would be written like: [block="16" Filtercode="2.c_name=events,2.id=3,[email protected]" max="30"]main_cc_embed[/block] That adds searching on a second set of data ('2'), filtering to a particular entry ID and filtering to ones where one of the values in the Colleges field matches the first (main, implied) data set. Allow for any number of AND lookups (2., 3., etc). |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
Docs...
If you want to make a filter match on another field (a field-to-field comparison), you can surround it in curly brackets like [tt]{Maker#Owner}[/tt]. In this example, we're selecting entries where the maker is the owner (so maybe unsold goods).
If we want to match against a condition in a(nother) catalogue, then we can do this using the dot notation. For example, [tt]events.id=3[/tt] would connect to a catalogue called [tt]events[/tt], connecting to records where the ID value is 3. This is the same as an "inner join" in SQL: you may wish to read up about these.
Both the above examples are quite contrived, but put together we can use them to define proper join conditions so that we can limit results based on a check into another catalogue.
For example, imagine this Filtercode was used on a catalogue named [tt]products[/tt]:
[tt]{Manufacturer=manufacturers.id},manufacturers.Trading=1[/tt]
This finds [tt]products[/tt] entries that have a manufacturer that is trading. It combines the [tt]products[/tt] catalogue with the [tt]manufacturers[/tt] catalogue, under the basis that the [tt]products[/tt] catalogue has a field named [tt]Manufacturer[/tt] that points to a [tt]manufacturers[/tt] entry. It then adds an additional check that will limit overall results so that only [tt]products[/tt] entries will be returned that can match to an [tt]manufacturers[/tt] entry where Trading is checked.
We do a field-to-field comparison across two catalogues, to make a match up, so that we can then add in a check on what we can match up. Note that if there are no matches across the two catalogues before the check is processed, this would be the same thing as the check not passing.
Another example, imagine this Filtercode was used on a catalogue named [tt]locations[/tt]:
[tt]{events.Venues#id},events.Performer=Justin Bieber[/tt]
This would find all locations that was a venue for an event performed by Justin Bieber. It combines the [tt]locations[/tt] catalogue with the [tt]events[/tt] catalogue, under the basis that the [tt]events[/tt] catalogue has a field named [tt]Venues[/tt] that points to multiple [tt]events[/tt] entries. It then adds an additional check that will limit overall results so that only [tt]locations[/tt] entries will be returned that can match to an [tt]events[/tt] entry where Justin Bieber is performing.