Wulfeh posted:

I was under the impression that class Meta ordering was "bad", something to do with inheritance, I forget. It was something mentioned by David Cramer at djangocon. Does anyone remember the exact reason why?

bitprophet posted:

I know that's probably a lot to absorb for a newbie, but if you read up just a little bit on Python importing and modules, it should make sense.

Wulfeh posted:

I was under the impression that class Meta ordering was "bad", something to do with inheritance, I forget. It was something mentioned by David Cramer at djangocon. Does anyone remember the exact reason why?

Mashi posted:

What's the best way to create an url in the format "/yyyy/mmm/dd/slug" given an url name and a model?

bitprophet posted:

Well, first off, Python is case sensitive, so are your field names really capitalized like that (Name and so forth)? If they are, then I don't see anything obviously wrong with your code -- but they should not be capitalized, as it's nonstandard Python naming (generally only class names get capitalized/camelcased, and everything else is lowercased with underscores, i.e. my_variable). Following a language's style is always a good idea as it makes collaboration with (or assistance from ) other coders, much easier.

Can you paste your model file? It will answer my above question, and the view and template are only two parts of the puzzle -- troubleshooting is always more difficult without the entire picture.

Finally, while I doubt this is your problem, keep in mind that the default string representation of Python objects happens to be HTML-tag-like (<MyObj foo>) so if you were ever to try and do {{ some_object }} it would look, in-browser, as if nothing was there. So a good tip is to always View Source when you don't see an expected string, in case this is what's going on.

However, you seem to be doing {{ object.attribute }} which usually doesn't have this problem (as the attribute values are typically simple values like strings and integers) so that's probably not what's going on -- but the phenomenon is good to keep in mind regardless

hitze posted:

code:

				{% for Song in song_results %}

I can't seem to get the songs to list or get called, so i'm hoping i'm missing something that should be really obvious. Any help would be appreciated

deimos posted:

try

code:

				{% for Song in Album.song_set %}

bitprophet posted:

hitze posted:

Well after rereading the docs for models and page 3 of the tutorial (for the upteenth time) I came up with this:

quote:

code:

AttributeError at /artist/led-zeppelin/
'Album' object has no attribute 'album_set'

deimos posted:

Gah, go back and re-read the tutorial and documentation, specifically this page.

1. Why do you insist on setting the albums and songs to a variable.
2. Why are you using get() when stuff might return more than one value? You use get to get a single instance.


For #1 you do not need to be declaring all those variables on your view.

Try this as your view:

code:

def artist_page(request, artist_slug):
	artist = get_object_or_404(Artist, Slug=artist_slug)
	return render_to_response('main/artist_page.html',
		{
			'artist_results': artist,
		},
		context_instance = RequestContext(request)
		)

And this for your template:

code:

{% for Album in artist_results.album_set %} 
	{{ Album.Name }}
	{% for Song in Album.song_set %} 
		{{ Song.Name }}
	{% endfor %}
{% endfor %}

That's because Album indeed does not have an album_set; artist has an album_set and each album in the album_set has a song_set.

WickedMetalHead posted:

Does unique_for_month still work?

I tried having a BooleanField set with unique_for_month="date" and also a CharField with choices and null/blank = True set to unique_for_month="date" and in both cases it allowed me to check the field twice or pick a choice twice.

nbv4 posted:

Does anyone have any experience using django-tagging with django 1.0? Is it stable? or alternatively a tagging system that works well with 1.0?

nbv4 posted:

django 1.0

king_kilr posted:

newforms-admin branch

bitprophet posted:

Is there some sort of neo-newforms-admin that continues to exist/be relevant post-1.0?

king_kilr posted:

yeah it should work fine, you need to use the newforms-admin branch though.

Murodese posted:

How do I stop recursive foreign keys from being able to choose themselves? I don't want a category to be able to pick itself as its parent :V

nbv4 posted:

Now I have another problem. I decided to split up one model into two models. Originally I had a model called "Music" which contained both CD's and records. Now I have one model for CD's, and another one for records.

I want to create a paginator that displays both CD's and records in order of date of release. Whats the best way to do this? Shpuld I make another model that somehow contains both all of the user's CD's and all of the user's records?

this is a stripped down snipplet of my code so far:

(snip)

nbv4 posted:

Does anyone have any experience using django-tagging with django 1.0? Is it stable? or alternatively a tagging system that works well with 1.0?

deimos posted:

THEY CHANGED THE DOCS INDEX PAGE AGAIN

pokeyman posted:

Check out model inheritance in the Django docs. I'd suggest making an abstract model called Music, then have CD and Record inherit from Music. Put your release_date and name fields in the Music model, then take them out of both CD and Record. Then, in your view, you just go Music.objects.all().order_by('release_date') and you're set.

What's going on here? An abstract model defines certain fields and lets you use the model as normal in Django, but in the database there's no mention of the abstract model. Instead, any submodels of the abstract model get (inherit) the abstract model's fields automatically. So in my outline above, both CD and Record get the release_date and name fields (which end up as columns in their respective database tables); Django will then interpret Music.objects.all() as you wanting all objects of models descending from Music, even though "Music" doesn't exist outside of Django; all of the tables that make up Music-derived models get joined together. Thus, any fields common to all Music should go in the Music model. You can, of course, specify more fields on a submodel (e.g. give Records a rotation speed), but you wouldn't be able to refer to it from the Music model (e.g. Music.objects.all().order_by('rotation_speed') won't do you much good).