Comments on: complex hierarchical taxonomies in drupal?

By: Martijn

Martijn — Thu, 29 May 2008 19:01:24 +0000

Hi,
I would also like an hierarchical solution, but I am thinking along the line of panels.
See my conversation with the panels 2 guys: http://drupal.org/node/231911
Will you be able to help to get this rocking?

greetings,
Martijn

By: dnorman

dnorman — Sun, 27 Apr 2008 23:16:34 +0000

Boris, I think I may have just thought of a possible solution. I’m wondering if this might be a viable candidate for a CCK custom field module? I could define things like “year” “institution” “program” etc… and provide dropdown selectors…

By: Spooof

Spooof — Fri, 25 Apr 2008 00:02:54 +0000

If you get this working I would love to know how easy it is to maintain. At work we have a requirement to track safety training for various individuals, expiry, etc. It appears that this would have similar requirements. Currently this is done in a crappy MS Access application and I would love to move it to our CMS. I have searched for various HR dupal modules but could not find anything close.

We already AD to authenticate and store most of the basic information in AD. All we would have to add is the course and date info.

By: dnorman

dnorman — Thu, 24 Apr 2008 23:25:56 +0000

hrm. yeah. that gets pretty messy.

if this was in custom-software-land, I’d just make it a many-to-many between a Person and a Degree, and have both Year and Institution be additional attributes of the join. But that’s not something that’s readily representable in Drupal parlance…

By: Boris Mann

Boris Mann — Thu, 24 Apr 2008 23:02:16 +0000

Actually, the messy bit is that you HAVE to have one degree per person – year combo — then it becomes a question of how much stuff you want to relate outside of that. But you will definitely have one row per year/person (the data has to live somewhere, it’s a matter of picking your join, and the year+degree related to person is the unique data).

Reading that, it sounds more complicated than it is

By: dnorman

dnorman — Thu, 24 Apr 2008 22:36:26 +0000

Thanks, Boris.

omfg. yeah. node relations are totally the way to go. it hit me on the way home. That Great Teachers site I linked to is essentially doing the same thing, but instead of “degrees” it is using “awards” – but it’s the same thing.

In that case, it’s modeled like this:

Person -> awarding -> Award

By putting the Year into the “awarding” level, the Award (or Degree) remains generic enough to be reusable, otherwise we’d wind up with hundreds or more of various incarnations of the same Degree (but from different institutions in different years).

I’ll try to hack something together. Think it’s getting closer…

By: Boris Mann

Boris Mann — Thu, 24 Apr 2008 22:00:17 +0000

CCK can do this.

Person –> noderef –> Degree

Degree:
* type (taxonomy or CCK text field with autocomplete) — e.g. bachelor
* year (date field, year only)
* institution (taxonomy, or noderef to a type Institution, or CCK text field with autocomplete)
* department (taxonomy or CCK text field with autocomplete) — e.g. Science

Think about each item you are modeling, and think if it has other information attached to it that would be useful to have as first class objects. E.g. Institution would actually have a location, and then you can start doing mashups of degrees across the country

As modeled above, the Degrees output for one person then becomes “show me all degrees for this given profile ID / user ID” — the degree contains the rest of the information.

Views Fast Search will let you model an advanced search form based on the fields.

Think less of inputs and more about data modelling. Multiple node refs are a good way to prototype this…but bundling this into custom relationships may be the way to go long term.