Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.CPyle and I are thinking of a module to generate dependent drop downs using views.
Our main idea is to use each drop down as a argument for the view, and the returned summary list would be the next subsequent drop down.
I was thinking about this earlier today and came to a couple different conclusions.
1. Each drop down could be a seperate cck field, and they would somehow have to be linked together.
2. A series of drop downs could be just a single cck field, and the last drop down would be the actual value stored.
2a. If this is the method used, would we want to store the path that they chose since they could take multiple paths to reach the same end choice.
Looking for input from people that are intimate with cck to help refine the idea before we do any coding.
Comments
Comment #1
corey.aufang commented(for ease of typing ddd = dependent drop down)
Thought of a way that 1 and 2 would actually be the same:
Each ddd field would need to choose which view they referenced, and which argument in the view that the field actually stores.
This way you could have the ddd cck field store the 3rd argument, it would generate the first two drop downs to get the value for the 3rd.
We would also need some way to store the "path" (which options that were used to reach the value for the final drop down in a set). The path could be stored in a hidden field on the page for easier form processing.
I'm not sure what would be best for that, I was just thinking a separate table for doing this. Table would only have to store the nid, vid, field name, and value of the "path" hidden field.
To have this bridge across multiple cck fields, we would need to have a way to link the ddds.
A ddd could specify which other field in a content type that it was dependant on. (you would need to specify whether to use the last value, use use its "path" and value for its first arguments.) Also it would provide drop downs for any intermediary arguments that were not provided.
Comment #2
corey.aufang commentedprob classified wrong to begin with
Comment #3
CPyle commentedThis was my initial proposition:
CCK Side
Create a new CCK field module. The only thing a user would need to specify when adding the field to a content type would be which view to use to generate the dropdown items. The view would need to be an acceptable view containing nested arguments to work properly. Titles of each argument in the form would be extracted from the view arguments, if used at all.
Schema: When a ddd field is used to obtain a value, the values of each argument used will be stored, similar to the way fields with multiple values currently store their data.
Views Integration
Referring to the schema used, new views handlers will be required. Upon selecting a field obtained through ddd, an option must be added to select which argument result to use, similar to selecting the delta of a cck field with multiple values, but represented by the argument title. Default to the last argument selected.
This approach solves the problem of having an overly complex ui set up needed to use the field, and also allows a user to select a value with varying levels of specificity. For instance, if a view could potentially have 4 arguments, but a particular argument 2 did not return further data, you could still use argument 2. Or simply select as far as argument 2 or 3. We could of course include an option to force a user to select as far down as required.
I'm unsure how to go about storing results from differing view types (eg. node, user, etc.) but I believe it could be done without having to create a separate module for each.
Comment #4
corey.aufang commentedCreating a new field type would at most allow you to store text, unless you are willing to create a new ddd field for each type (node ref, user ref, integer) that you wanted to use.
Creating a new field widget to handle ddds would make more sense as it would allow you to use that widget for any field type, without having to redo functionality of field types that exist already.
Comment #5
CPyle commentedI don't follow your reasoning as to why I'd only be able to store text, considering I have access to the view results. You key the options array in the dropdown based on the primary key of the table used in the view.
If you have a node view, you use nid for the key of the options array. If you have a user view, you key it with the uid. You are storing the nid or uid in those cases, respectively. Its the exact same way that current node and user references store their values. There is zero difference. And you don't have to create a separate widget to handle each base table type, you just get the base table from the view and key the options array with that table's primary key. If the primary key isn't present, it can be added. If you look at node and userref, this is exactly what they do. In fact, this method could probably be used as a starting point to consolidate noderef and userref into a single module. All you have to do is add the appropriate field handler on the views integration side.
Comment #6
corey.aufang commentedOne of my main concerns is that i don't to make something that forces users into using new field types to support ddd functionality.
The way I would like to develop this module is to make it add ddd functionality to existing field types that can have drop downs.
I don't want to make replacements for field types, they work very well as they are. Also, every change and update to the core content types would have to be ported.
Comment #7
CPyle commentedThen you will have to write it to separately handle each CCK field type that currently exists that can reference a table that views uses. And then you still have the problem of storing more than one variable in a way that is still usable by views. Which means basically doing what I said, only doing it over and over, and doing it in a way that piggybacks onto other peoples' code.
What do core content types have anything to do with this? Do you think they are going to rename or remove the nid column soon?
Extending other cck fields via a module will actually have the effect of our module needing to be rewritten when nodereference, userreference, taxonomy, etc. changes in a way that affects how it uses views. Whereas if it is standalone, that would never be a problem. It is much more intuitive to create this as a standalone module. It's one module. One CCK field. It would support users, nodes, taxonomy, and anything else that views can reference, in one module, with one purpose. Writing an addon module that has code for individually extending every applicable CCK field module out there makes no sense.
Comment #8
corey.aufang commentedI don't envision making the "path" available to views.
If you wanted to store the "path" for use by views, I would make each step a separate field in the content type.
Also, I wasn't planning on having the ddd module interact with the content types that much at all, all it really needs to do it interact with the drop downs themselves.
Being that the module would only really work with the drop downs, you don't have to re-do core for each field type.
Field value validation would be taken care of by the core field types.
The meat of this would be the JS that handles the actual select lists, and the call back the interacts with the views and returns the data.
The "path" would be extracted from the form through a standard hook, which I would store in a separate table.
Comment #9
corey.aufang commentedAlso, the path that would be stored in the seperate table would only be the select lists that were not stored in the node.