Unify the "multilevel" and "hierarchical" cck selection widgets for nodereferencing

Problem

There are many modules that provide half solutions to the problem of referencing nodes in a hierarchical nature. We spoke with webchick about this tonight as a matter of fact. The probnlem rather simply is that while you can use nodereference field to relate nodes (and types) hierarchically ("My car" references "CVR" which references "Honda") this prevents you form storing that information with the actual node for use in views (sorting, filtering, etc) because only 1 portion (the first parent) of the relationship is stored at any level.

Possible Solutions

2 solutions seem apparent:

• design a good way to pull in these extended relationships to views for use
• store every level of the relationship with the children and use views as usual.

The second solution is already possible but has 2 drawbacks:
+ you can select nonsensical values because the fields arent "linked" to enforce referential integrity (e.g. Honda F-150 Truck is an invalid but possible selection with 2 node reference selection fields.
+ you have to sort through all thos invalid entries to find th eone you know s valid even though you created all the information to "know" this as you created the hierarchy above via node reference.

Proposed development

The open to suggestion but proposed solution for this problem would provide a cck field that allows you to spell out the relationships between content types (Manufacturer > Model > My Car) and the fields by which they relate to each other (nodereference). It would then provide the node creating and editing user with multiple select fields that are auto populated and updated (via AJAX) as the user selects down the hierarchy.

Usage Scenario

• Admin A creates a manufacturer node "honda"
• Admin A creates a model "CRV" and assigns the nodereference field (restricted by type manufacturer) on it to point to Honda as the manufacturer
• Admin A creates the car content type and adds the field that this proposed module would provide. this felds setting area asks him to select the content types and the fields that describe how they relate (A > B > C ... N).
• User wants to create a new "car" in the system to show pictures or sell it or something (imagine a music track if youd rather, or a city selection widget that uses sparql queries for the info).
• User A navigates to node/add/car and selects the manufacturer "Honda". The widget then assembles a list of all of the nodes that reference Honda using the node reference field that the administrator indicated. It populates those values into the next selection widget and repeats the process as necessary to drill down to the desired level.
• User A can change any higher level selection and have the widget respond accordingly by removing the children select inputs and populating the correct new child select.
• User A submits the form and EACH level of the selection widget is stored with the node so it can be queried and used in views for sorting, argument and filtering along with dozens of other uses.

Related development to unify and beg borrow and steal from:

• http://drupal.org/project/activeselect
• http://drupal.org/project/dependantDropdown
• http://drupal.org/project/dependent
• http://drupal.org/project/nr_autocomplete
• http://drupal.org/project/hierarchical_select
• http://drupal.org/project/multiselect (less so really)

With all of this seemingly related work i think we can carve out a strong module that satisfies the use cases at hand in an organized and robust fashion so we dotn have so much duplication and can integrate their functionality little better at least. If there is any interest im willing to flesh this out a further, contact module developers in question, and mentor a student.