2

I have a Book model that needs two separate Tag fields: genre and tags. I'm considering whether it would be better to write my own Genre and BookTag models for this, and linking it with ManyToManyFields or using DjangoTagging to achieve the same.

Ultimately, I need users to be able to filter either according to genre, or according to tag, but I don't need the Tag Cloud functionality.

From what I can see, Django Tagging allows two TagFields, but then it casts both into the same tag cloud. That's not a problem for me, but before I start refactoring all my code to use Django Tagging instead of my own ManyToMany fields, are there any other catches of using Django Tagging in this situation that I should be aware of?

Herman Schaaf
  • 46,821
  • 21
  • 100
  • 139

1 Answers1

4

Negatives

  • Django tag fields don't have slug fields so you will manually have to slugify the tag.name if you want to use them in Urls

  • You can't (without subclassing django-taggings models) add any other fields to a genre or book tag so you won't easily be able to describe the genre or tag.

  • Regarding useability: If you are using django-tagging you will more then likely be using a TagField to enter the tags (be them genres or booktags). The problem with this is that you need to remember exactly what tags you have used before, as opposed to a foreignkey or manytomanyfield where you are selecting from a list.

Positives

  • Django tagging has a nice API for querying tags and tagged items

django-taggit is another tagging application that is widely used and still developed and overcomes some of the above limitations

Timmy O'Mahony
  • 53,000
  • 18
  • 155
  • 177
  • Thanks, very useful! I see your point with the usability thing, but I think that becomes a positive when you have thousands of tags, and you combine it with an AJAX suggestion script. Not having slug fields automatically sucks, but not too hard to fix. As for django-taggit, what are the relative advantages? – Herman Schaaf Nov 02 '11 at 10:31
  • 1
    It has slug fields and it's extensible so you can overcome problems such as point 2 https://github.com/alex/django-taggit/blob/master/docs/custom_tagging.txt – Timmy O'Mahony Nov 02 '11 at 10:41
  • Django Taggit it will be, particularly because of the extensibility of using your own Tag model - looks like a perfect fit! Thanks! – Herman Schaaf Nov 02 '11 at 11:40
  • I've also convinced myself to switch over I think! – Timmy O'Mahony Nov 02 '11 at 11:43