Save term lineage requires a "Multiple values" content_taxonomy field

A term lineage typically consists of multiple values, so you have to configure to enable the "Multiple values" setting of the content_taxonomy field!

I'll have to document this better.

I need to update that in the docs too. I assumed that since the "save as tag" save option works, "both" would work as well. I guess that's not true. So I'm only going to support the "save as tag" save option.

Done!

Isn't saving terms as both tags and cck tables an important feature of content taxonomy? Like if you have address taxonomy fields and want to save the location as tags for searching, and the cck table will take care of displaying the location to users. This is how I am building my current site to function with content taxonomy.

I honestly have no idea. Why can't normal taxonomy be used for displaying the selected terms? In the end, you have to theme either approach (taxonomy for display versus CCK for display). "Both" means you're storing the exact same data twice. That, and there's an API to acces the information in Taxonomy's tables. That doesn't leave many advantages for "both" or "cck" as save options.

The real problem is that content_taxonomy messes things up internally; does it make sense to you that a widget only works properly with ONE of the three save options? It doesn't to me. I don't have the time or interest to spend even more hours on finding out how that's supposed to work. Patches are welcomed of course.

I agree to theming the tags that way so it's not stored twice. But I think this would be harder than it appears (though I have almost zero knowledge of theming Drupal) mostly because the tags need to be displayed in the right order. When I begin theming my site I'll try to find out if this can be done.

Saving the data as just a tag and not a cck doesnt allow for very much flexibility in displaying the view.

For Example:
-I want a user to select his make and model of his vehicle.
-I want to display the users data w/ views and have it sortable via columns like so: username | make | model

if its only the node is only tagged for taxonomy, I cant separate make/model in views 1 (I dont know about views 2)

This is why I need BOTH cck and tags to work.

And how exactly are you able to separate them when it's saved to the CCK tables?

I have been using this widget (which you stated has some redundant code to your own): http://drupal.org/node/180687

It allows you to create multiple cck fields, one would be 'make' another would be 'model', the first field references the second. When you use the form it acts like activeselect but gives you two cck fields for views. The problem is you have to create a field for every term level.

Could HS store the multiple pieces of information just by adding a number to the end of it?
Example:
my field is called field_make_model and the user uses HS to select make and model, then they are both stored as field_make_model and field_make_model_2.

possible?

Nope, not possible, at least not easily.

And this is not a "problem" in HS, it's more a problem in Views 1. I believe Views 2 makes it easier to show multiple columns for one entity. In Views 1, it's also possible to display multiple fields, but you'll have to do some coding.

As you can see, Views is *not* the holy grail. It's got many limitations as well. This is why it's sometimes more sensible to write your own query instead ;)

I would also very much like to be able to have HS save "both" tag and CCK value. Here is the reason why I would like to do so. Maybe there is a better way to meet my needs.

CCK is great to define custom forms, and display the resulting data. With the standard display parameters of CCK, in most cases the only work I have to do to theme the form/display of the node, is to define the appropriate CSS.
However when you want to have input from structured lists, CCK is very limited.

Taxonomies however are great to manage structured lists. I could use taxonomies for the input, however the standard way taxonomies are displayed really do not meet my needs: all vocabularies are mixed up. It's not difficult to display taxonomies per vocabulary, and I could easily add that to my templates. However in a mixed context, where part of the input comes from CCK, and part from taxonomies, you have to hand code the display of all fields in the template, i.e. you lose all the benefits of CCK to manage the theming of the forms results.

Content Taxonomy enables me to get the best from both CCK and taxonomies.
It is obvious that it is less efficient to store both the taxonomy and CCK field value, but I guess that if the Content Taxonomy developer decided to enable this, it is to maximize the compatibility with all the modules which are based either on CCK or Taxonomy (and there are many). I like the flexibility this "both" option enables, and I'm using it.

I find great that you increased in v.3 your support of Content Taxonomy by providing a specific "Hierarchical Select" widget to select in the setup of a Taxonomy Field. It would be even better if you supported the "Both" Save options. Is it difficult to support this option in HS?

Well, I'm using "save as tag" and I STILL get to see my taxonomy data as a CCK field, but *also* as a normal taxonomy. So all you'd have to do, is remove the taxonomy stuff. You can do this by using hook_link_alter().

As nice as your use case is, writing widgets for content_taxonomy truly is a terrible, awful, nightmare-ish experience. That's why it's difficult to support this: I wrote a widget, so the field should work with whatever save options it supports. *BUT* for some mysterious reason, it does NOT. I don't have the time, and in this case not the energy to get this to work. If you want to get this working, you'll need to convince content_taxonomy's maintainer to step up to fix that.
But if you look at its issue queue, you'll see there are MANY issues with that module, many of which have been unresolved for months. In fact I shouldn't be supporting that module at all, I think, but I have to, because some people are using it. That's why I choose to only support "save as tag", because it's the only save option that seems to be working reliably (probably because it uses Drupal core's Taxonomy module).

subscribing