noisebridge / pyclass-project

Other
8 stars 2 forks source link

Add tag details page #37

Open Belgand opened 12 years ago

Belgand commented 12 years ago

Simply this is a page that will be linked to when a user clicks on a tag. I was thinking that a listing of all ToDo items that contain it makes the most sense. This would be very similar to the details page for Interests.

Keep in mind that the list of items contained in a many-to-many field can be accessed by the model that didn't define the field by adding "_set" to the model name unless another name is given with "related_name=" in the many-to-many definition. So if Model1 is defined and then Model2 defines a many-to-many relationship to Model1 Model1 would be able to get the list of Model2 objects that contain it by using Model1.model2_set.all(). Since Model2 defined the relationship it would only need to use Model2.model1.all()

In this case that means that tag.todoitem_set.all() should contain all of the todoitem objects that contain the tag object "tag".

Belgand commented 12 years ago

We probably shouldn't be trying to look up tags based on their name. For one thing the get_absolute_url method for them wants to look them up based on primary key. This is a more sensible method since it involves less searching and ambiguity. After all, this isn't a page to search for an unknown tag, but one to display the information for an already known tag. What if a user clicks on a link for a tag to get more details and that tag happens to have a very similar name to another tag? Depending on how we search and manage the data it might pull up the wrong record. Actually, in our current database schema there's nothing preventing two tags from having the exact same name since they aren't currently required to be unique. A primary key would be unambiguous and regular since it isn't created by users and is always required to be unique.

kellanjacobs commented 12 years ago

Mark, I actually disagree with you on this one. We should be using tag names in the URL. This is the reason django has a slug field. It is for creating these types of URLs. SEO issues aside you should make your URLs as easy to use for your users as possible. And names are always better than numbers. The first paragraph in this article from Google states this. http://support.google.com/webmasters/bin/answer.py?hl=en&answer=76329

Belgand commented 12 years ago

I thought about that a while back when I was working on Interests. The thing that bothered me about it was that it would mean that the slug would pretty much be identical to the name except slightly more constrained. Just using a slug would likely restrict users too much and leave us with ugly tags. Considering those are the only fields it has it seemed like the duplication wasn't worth it.

It also meant an increase in the amount of effort needed to automatically create a slug from the name field. AFAIK Django only has the option to do this in the admin.

I see why this is a good idea and it was my first thought, but it just seemed like it wasn't going to be worth the hassle.