Going through the Drupal documentation on "Organising content with taxonomies", one of the guidelines is to divide up vocabularies when parent-child relationships are required and the number of terms is high.
In a properly designed database environment, tables are joined by "foreign keys". If I use the table analogy with vocabularies, I would like to know if this works (or can work) the same way. Let me try to explain.
First use case:
Imagine a user profile page, in which a user can select a motorcycle brand via a term reference field linked to a vocabulary storing all available brands. This vocabulary has the brand listed in its description, while a field is added to store an integer, that acts as a unique "foreign key".
What I want:
when the user selects the brand in the user profile page, the brand name should be visible in the field, but I would like its underlying field (on the user profile page) to store the "key", and not the text in the description.
Benefits:
if for whatever reason I need to change the description/brand name, the user profile for all users with the same motorcycle brand will automatically show the change.
Second use case:
A first vocabulary stores all kind of motorcycle brands. This vocabulary has the brand listed in the description, while a field is added to store an integer, that acts as an unique "foreign key".
A second vocabulary stores only motorcycle types, a field that acts as the unique key for the type, while a second field stores a link to the corresponding brand.
What I want:
to use the unique brand key, as a "foreign key" to reference/link to the brand name in the motorcycle type vocabulary.
Benefits:
a) I am not storing dozens of the same motor brand in text form in the motor type vocabulary, b) if for whatever reason I need to change the brand name description (in the brand vocabulary), I do not have to update the motor type vocabulary, c) by selecting the motor type in any kind of content type, I have automatically access to the brand that is linked to it.
Right now I have played around establishing a parent-child relationship by using a term reference field. But that only allows me to store the description text, not the "key". There is no way (as I see it) to do what I describe above. And frankly, this to me defeats the purpose of parent-child relationships altogether. So I guess I must be missing something.... and could use some help from the community.
Just to be clear, I am a fairly new Drupal site developer, a hobbyist, have done lots and lots of reading & searching on internet about Drupal (including on this topic). Working on my very first web site for a couple of months now, but I am by no means a coder (although willing to learn). As such I am lacking a full overview on Drupal's capabilities (if that is at all possible...). Any pointers into the right direction would be extremely helpful.
Comments
Not sure whether this works
Not sure whether this works but bear in mind taxonomy terms are fieldable. So you could view your term as a key, and a particular field (which is what you would choose to display) as the variable value.
A Drupaller would typically react to these types of use case by thinking of Node Reference, User Reference or Entity Reference modules. You should also read the project page for Relation https://drupal.org/project/relation. However if you can achieve what you want with taxonomy it is may be the least expensive solution in performance terms.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
Well, it might
Thank you for the pointers. Will certainly look into the "Relation" module to see if that is what I can use. But for selection lists to be used in fields I like the taxonomy way of keeping related "entities" together, and not create individual entities for each entry, so not sure if that would be a route I would want to go. But will look into it.
I have already enabled the Entity Reference module, but not used it yet and never thought about using it for this use case... Will look into this also.
In the mean time, as my vocabularies are already fielded with keys, could you expand a little more on what you mean exactly by?:
Are you by any means referring to the "Views Field"? I need to get my head around the functionality of that module also.
Lots to learn still....
I am not 100% sure what I
I am not 100% sure what I said makes sense! And there is no reason the main field or the taxonomy term would have to be the field select to act as 'foreign key'.
You certainly need to learn Views, which is really indispensable but not simple to learn. If you are a developer you can view it as an sql query builder. For accessible introductions, in addition to excellent video tutorial, both paid, and the free Taming the Beast series, I can recommend the book Drupal's Building Blocks.
When using Views, you call a selection of fields, mainly fields you want to display. It is possible to include one or more fields where you tick 'exclude from display'. These hidden fields are there in effect to act as keys, and can be used to create a 'relationship' in the advanced section of Views, or hidden fields can be used (more simply) to group results by. Creating relationships is advanced usage of Views, and can get frustrating to work out, so it is probably best to get comfortable with the more straightforward ways to use that module first.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
By now I have figured out
By now I have figured out that the "Relation" module is not what I am looking for. And although I have not yet figured it out completely, the "Entity Reference" module, in combination with the "Views" module, seems to be the way to go. I need to find out the proper way to establish a solid relationship between multiple vocabularies, but with a Term Reference field I think I will be getting there.
The one thing I am not sure about is on how to pass a view argument to the entity reference view that I created. The option when editing the field (i.e. "View Arguments" which is an option when selecting to use "View" as a mode for the entity reference field) is for a hard-coded argument, which is not what I can use. Could I use a wildcard for this?
Use case: User selects a motor brand (straight from a term reference field). This selection should be used to filter the entity reference view that should result in a list of all motor types that are related to the selected motor brand.
Thanks once again for your feedback so far. It is helping!
i am not following well.
i am not following well. First a Veiws Argument has been renamed to Contextual Filter, so I wonder whether you have tried this yet. Second in your use case you say 'related' to the selected brand. Usually in this situation people are talking about hierarchy (all the models of car made by BMW or Honda etc.). so here one is using taxonomy terms in a hierarchy (which is built in): not sure if your 'related to' is the type of relationship which can be done hierarchically.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
Sorry John, it must be my
Sorry John, it must be my English or me having to come to grips with using correct Drupal terminology consistently. Let me try to explain better:
When I used the words 'related to', I indeed am referring to a hierarchy in taxonomy terms. But not a hierarchy that is defined in one and the same vocabulary, but in a parent-child relationship between two separate vocabularies (which is really what started this thread). Where the parent is a vocabulary (called "Motor Brands") storing all the motor brands as taxonomy terms, and the child vocabulary (called "Motor Types") stores all motor types in taxonomy terms, with a custom field storing a reference to the motor type (which is the vid of the brand name of the motor type):
Vocabulary "Motor Brands":
Name- BMW
- Honda
- Yamaha
- ......
Vocabulary "Motor Types":
Name |Field (entity reference)- RT1250 |vid of "BMW"
- K1300S |vid of "BMW"
- FJR1300 |vid of "Yamaha"
- ......
The vid of the motor brand is the way I have the parent-child relation defined. Hope I explained it better this time....
Coming to the first part in your reaction => let me try to explain:
I have a content type called "Motor Info". Included is a term reference field from which the user selects the motor brand. Another field is added from which the user should be able to select a motor type. But I want that field to only show the motor types that 'relate' to the motor brand that the user already selected (i.e. if 'BMW' is selected, only BMW types should be shown in the select list).
Based on your input I am now using an entity reference field for selecting the motor type. I just learned that I can use 'Views' as a mode for the entity selection. I therefore created a simple View (with an "Entity Reference" display) that retrieves each and every motor type. But I want it to only retrieve the types that are relevant for the brand name that was already selected. In this context I used the words "View Arguments", as this is an option of the entity selection of the field in my content type.
I am just looking for a way to provide the already selected brand as an 'argument' for the view, so that only the related types are shown in the selection box. I have not figured this one out yet.
By the way: this is similar type of functionality that the "Reference field option limit" module provides. But I do not want to use it, as in order to filter the selection list for a second (related) field, it expects a text value to filter on (so e.g. "BMW" instead of the vid of that term). I definitely do not want to use a hard coded text entry to filter on (as explained in the very first post in this thread).
Not sure if this makes more sense now?
OK. It is still not clear to
OK. It is still not clear to me why you prefer Entity reference to the motor types to using the built-in parent child relationship system which is possible in a single vocabulary. (This parent - child relationship in Taxonomy is distinct from the alternative method of adding a field, potentially a taxonomy field, to a term, AFAIK).
As for displaying based on a previous selection, the answer is the Hierarchical Seelects, or (because that module seems to lack much prospect of a stable D7 release) https://drupal.org/project/shs.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors