views:

24

answers:

1

This is more of a best-practices question, and given that I'm quite tired it mightn't make much sense.

I've been putting together a blog app as a learning experience and as an actual part of a website I am developing.

I've designed it like most apps so that you can list blog posts by multiple criteria i.e.

/blog/categories/
/blog/authors/
/blog/tags/
/blog/popular/
etc.

On each page above I also want to list how many entries are a part of that criteria

i.e. for "categories", I want /blog/categories/ to list all the different categories, but also mention how many blog posts are in that category, and possibly list those entries.

Django seems to give you lots of ways of doing this, but not much indication on what's best in terms of flexibility, reusability and security.

I've noticed that you can either

A: Use generic/very light views, pass a queryset to the template, and gather any remaining necessary information using custom template tags.

i.e. pass the queryset containing the categories, and for each category use a template tag to fetch the entries for that category

or B: Use custom/heavy views, pass one or more querysets + extra necessary information through the view, and use less template tags to fetch information.

i.e. pass a list of dictionaries that contains the categories + their entries.

The way I see it is that the view is there to take in HTTP requests, gather the required information (specific to what's been requested) and pass the HTTP request and Context to be rendered. Template tags should be used to fetch superflous information that isn't particularly related to the current template, (i.e. get the latest entries in a blog, or the most popular entries, but they can really do whatever you like.)

This lack of definition (or ignorance on my part) is starting to get to me, and I'd like to be consistent in my design and implementation, so any input is welcome!

A: 

I'd say that your understanding is quite right. The main method of gathering information and rendering it via a template is always the view. Template tags are there for any extra information and processing you might need to do, perhaps across multiple views, that is not directly related to the view you're rendering.

You shouldn't worry about making your views generic. That's what the built-in generic views are for, after all. Once you need to start stepping outside what they provide, then you should definitely make them specific to your use cases. You might of course find some common functionality that is used in multiple views, in which case you can factor that out into a separate function or even a context processor, but on the whole a view is a standalone bit of code for a particular specific use.

Daniel Roseman