Use Taxonomy for Experience Levels

It's not clear how the problem you identified (making additions/deletions/changes) is a problem with cck and not a problem with taxonomy.

The advantage you mention is something that could be created as a filter/argument on a view, right?

I believe one of the main reason it's cck is because taxonomy is not currently exportable with features.

It's correct that CCK field values has longer had exportable suppor than taxonomy.

UUID_Features now supports exporting vocabularies and taxonomy terms.

Still, as greggles points out, it's not clear how switching to taxonomy from CCK for session track and experience level provides an advantage over CCK.

I suppose taxonomy's default clickable terms make finding similar content slightly easier than building a view and themeing the field differently.

I'm not sure this makes it worth switching architectures. @bryrock or anyone else - can you comment?

I started to build a site using Cod on D6. I just decided to build the site in d7 since I can wait a few months for the cod d7 distribution, so everything I say is oriented to this switch.

The ability to both add fields to a taxonomy, and insert taxonomies as fields in d7 is very helpful for quickly creating pages which bring together all sessions/bofs/people who are associated with a taxonomy term. A tax view on a session type (in my case) "AAR" (an abbreviation for a society) can bring together sessions tagged with AAR, people who are members of AAR, and also output the fields associated with the tag (the location, website, etc., of that society).

I am not sure that CCK can't do this, it is just that I find it easier to do with Tags. Nor can I speak to the exportability via features. But once I get my hands on a d7 version, this is likely one of the first changes I will make to the session content types.

And if I can help test (not a coder, but I am very good at breaking someone else's code and suggesting fixes, really, it is a special gift I apparently have), let me know.

if using the CCK fields as defined in COD for session track and experience levels, you cannot change the allowed values for those fields in the session content type after actual session nodes have been created. So if you have a need to change or add additional tracks or experience levels, etc., for assigning to sessions, after you've already begun accepting session nodes, well, you won't be able to.

If you define the available CCK field values as key|value, you can add available values and change existing ones as long as they keys stay the same. Doesn't that address your need?

It's worth having these as taxonomy so that they may be readily edited by the site maintainer and still have the features show as "Default". I would recommend to have hook_install/hook_enable manually insert the initial terms into the vocabularies rather than handling those via Features, that way they can be removed, edited, etc without fear of making the feature show as "Overridden".

I started to use COD for our Drupalcamp in São Paulo(groups.drupal.org/node/273048), and was surprised to see this approach, and came here to see if anyone was talking about. As i guess, more people agree that it could be changed.

In my opinion, we should be talking about what we are keeping in this field. It's a list of something? No. It's a categorization. It's a taxonomy, a way to organize the content, so it seems inadequate to not use the Taxonomy module for this. It's a fact that we can copy this behaviour using a key|value list, but it's more organized, from my point of view, to keep as terms from a vocab.

Technically saying, "Track 1|Track 1" could lead to many future problems, because the key is a text that could be misspelled, etc, and if something would have to be changed, people could have problems to do that.

I'm putting my hands on it right now and could help, if you agree to change.

In the interest of keeping Features maintainable, I'd like to see this happen, as well. As it currently stands, if a site wants to change track or experience level allowed values, they'll override the session content type and have an overridden Feature.

I'd love to see this.

track vocabulary has been to COD 7.x-1.x but I don't think experience level yet. Not sure if we need that field either in stock cod, as its not relevant to all conferences (whereas tracks pretty much is)

@japerry: I'd suggest that if Experience isn't going to be changed to a vocabulary then it should be simply removed.

Retitling to indicate just experience levels. Tracks are already updated and using og_vocabulary.

In general, I think its correct that we don't want these values hard coded. Unfortunately it seems everyone using cod (that reports back) doesn't need anything else.