View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 996 | Composr | catalogues | public | 2013-01-27 20:21 | 2014-05-26 12:35 |
| Reporter | Robbie Goacher | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 996: Allow catalogue embedding blocks to perform reverse-lookups on linked data | ||||
| 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. | ||||
| 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). | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Time estimation (hours) | 6 | ||||
| Sponsorship open | |||||
|
|
Simplifying this syntax. I am making the assumption that you only ever need to join into a particular catalogue once, which is pretty reasonable. 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. |
