Tags should carry the context, not taggings

[the8472]

Proposal: The context field should be stored in the tags table instead of the taggings.

Usecase 1: Predefining Tags for a specific context and suggesting them to the user.
Usecase 2: Augmenting the Tag class by adding color or image fields to make the way a tag is displayed configureable. Or to add descriptions to a Tag.

Neither is currently possible because identically-named tags from different namespaces share the same Tags record, even if they have semantically completely different meanings and just coincidentally happen to have the same name.

[artemk]

Can you post a gist with real life models examples and pseudo use cases. Maybe it is possible to achieve your needs w/o rewriting gem.

[PikachuEXE]

Sometimes there is a use case like this:
A "tag" (with a string as name/ID) should only have one "type" (context?)
e.g. Picture posting site
Changing a tag's type should affect all taggings

But I don't think it is necessary to change table structure
Since there is also use case like:
User.skill_list = ["programming"]
User.hobby_list = ["programming"]

So the current table list works great for the second use case, but need extra effort to achieve the first one
BTW I also want to know how to do the first one using this gem. Anyone tried that before?

[artemk]

@PikachuEXE i don't understand why you want specific tag to be assigned only for specific context? Maybe you are trying to achieve some goal with incorrect instruments? Explain WHY you need this.

[PikachuEXE]

I have seen some websites use this interface
So that user can edit tags within one box
But then to do this a tag must only belong to one context

[artemk]

I don't get why it should belong only to one context. When you change name of tag in this form NEW tag would be created and old one will remain in table.

[PikachuEXE]

Forgot to show you the tag list

The text field manage tag in ALL contexts
So if a tag called "solo" belongs to "category",
typing "solo" in that text field will bind a item to the tag "solo" in "category", not creating a new tag in other contexts

[artemk]

tag itself does not belong to anything. So you can't say tag belongs to smth, it is independent entry. When you tag some category with Tag named solo, than Tag with name solo created. When you change this category.tag_list to "solo2", new Tag is created, and associated with that category. Old Tag with name 'solo' still in db. When you do another_category.skill_list = "solo", new Tag entry is not created but used old one. When you do one_more_another_category.some_other_list = "solo", also no new Tag entry is created, old Tag with "solo" is used.

If you need to find categories for particular context you can do it.

[PikachuEXE]

I am just saying there is use case that has such constraint,
Not suggesting/supporting table tag change (take a look @ my first comment in this issue)

I am just interested if the first use case can be done
(manage all tags in all context in one box)

[artemk]

manage all tags in all context in one box - is not doable. You can monkey patch gem to achieve that.

[PikachuEXE]

I see
BTW the wiki about delimiter is not updated
Should be ActsAsTaggableOn.delimiter = ' ' # use space as delimiter

[ches]

I have run into the OP's first use case as a limitation as well. For the second, using a subclass for custom behavior would be the logical thing to do -- what might be great though is if acts_as_taggable_on had an option similar to :class_name to specify your custom subclass in the association. Real-world (abbreviated) example:

class Topic < ActsAsTaggableOn::Tag
  has_many :follows, :as => :followable
  has_many :followers,
           :through => :follows,
           :source => :user,
           :class_name => 'User'
end

class Discussion < ActiveRecord::Base
  acts_as_taggable_on :topics
end

This works fine for calling methods off of Topic and instances of it, but of course going the other way falls over:

@discussion.topics.first.followers  # => NoMethodError for ActsAsTaggableOn::Tag

[ches]

Cool, fixed the above easily enough by simply manually overriding after the acts_as_taggable_on call:

class Discussion < ActiveRecord::Base
  acts_as_taggable_on :topics
  has_many :topics, :through => :topic_taggings, :source => :tag, :class_name => "Topic"
end

I'll see about getting a pull request whipped up to make this an option.

[artemk]

@ches looking forward.

[urkle]

My use case for having context in the tags table is as follows.

I have a model that has many tag sets to store attributes about a Driver

class Driver < ActiveRecord::Base
    acts_as_taggable_on :equipment_skills, :benefits, :preferences
end

All of these have predefined allowable values for them. However in order to facilitate it I have to have another model that simply lists tags & contexts. Now, initially that seems ok, as the UI can just pull from the "AllowedTags" model when presenting the UI.. However it can complicates certain query types such as tag_counts. As ideally [the customer] would like to see all available skills, even if no one has it (thus count 0).

Moving context to the tags model, however does add increased db storage overhead, and possibly db load in doing some queries.

And the original use case of this issue is kinda neat as well. e.g. in a "freely" tagged tag type, being able to add attributes to that tag after-the-fact. e.g. colors, icons, etc.. Now I could see that being done with a secondary model with a has_one or has_many join against tags. and the secondary model would either be only for a specific context (has_one), OR would have a :context field (has_many). then all the application specific attributes could be placed within the application model and not the gem model. (probably cleaner approach for forward compatibility with the gem).

Some niceties that would help make some of these happen easier is, having an options of :class_name to the acts_as_taggable_on model method to allow overriding the child class for a relationship (@ches's use-case) or somehow having the "easy" ability to define relative associations on the core models.. e.g. a "tag_details" model kind of thing maybe.

Anyways, just some thoughts on the topic.. and thank you VERY Much for this wonderful gem in the first place..

[the8472]

Adding STI behavior only covers usecase 2 if the unique-constraint on the tags is expanded to <type,name> instead of just as it may be necessary to have a tag of the same name in different contexts (i.e. subclasses).

[hazah]

For a very good example of use cases where tags would belong to specific categories (rather than the tagging) see drupal's concept of 'vocabulary'. This isn't to promote it in anyway, it's just that there's a ton of very useful information on the subject.

[tilsammans]

I am closing this issue for now.

I think the focus of acts-as-taggable-on should remain in providing tagging functionality that everyone is familiar with. That is to say, freely adding words to a piece of content.

The use case described is certainly a valid one, but I think it too specific to be included in this gem. If you require such a functionality, in my opinion you must put it in your own models and not rely on a plugin. By writing your own models, you are signaling the importance of what you want. And hopefully you are adding tests for it too.