On Thu, 2008-01-10 at 23:18 -0800, Darthmahon wrote: > Thanks for the reply, I've also just found out about context > processors, which to me sound extremely similar to templatetags. The > only problem I can see with both of these options is that I can't see > how you pass extra options into them, whereas you can if the logic is > contained within views.py > > I think Django is great, but there are at least three different ways > to do what I want which I think is almost too many options as I'm left > utterly confused as to which is appropriate for the situation. Your > answer makes sense, but how do context processors fit into all of > this?
Context processors are run once when you create a RequestContext instance. They can inject data into the rendering context based on the "request" object they are passed. They are given no other parameters (in particular, none of the other parameters that are passed to the view, although you could work out the URL again from the request if you needed to) and each context processor is run for every RequestContext. So context processors are a bit all-or-nothing: if you don't need any of them, you pass the template renderer a Context instance and no context processors are run; if you want them to run, you pass the renderer a RequestContext and they all run. Generally, the data provided by context processors is something that might be appropriate regardless of the response being rendered (although you don't have to use the data just because it's there). Template tags render methods are called each time the tag is used in a template. They have access to the context that is being used to render the template and return a string that is inserted into the template output (in place of the tag) and can optionally also modify the context dictionary. Since they are only called when you specify the tag, they are more useful for something that doesn't have to be done every single time. On the other hand, you do have to include them every time you want them to be run (whereas context processors are all run whenever you use RequestContext). Template tags can be much more situation-specific than context processors, since the full context will have been created and they have access to all of it. Views are more over-arching. Their real power increase over template tags and context processors is that they get to decide which main template to render and even if you want to render a template at all (they could return an HTTP redirect, or some kind of error). Generally, you're going to have a particular HTTP request needing a particular template and some data associated with that specific template that isn't really common to anything else. That's the view's responsibility. If you some small pieces of data that are used in multiple templates and whose output can be derived solely from the context dictionary, you can use a template tag so that you don't have to collect the data in every view that uses those templates. If you have some data that needs to appear in every template (or many templates) and that can be derived solely from the incoming request object, you can use a context processor to insert the data into the context and then use template variables to put that data into the templates when you need to. Also, template tags and context processors are primarily concerned with data presentation, whereas views are more over-arching are the logical place for logic such as creating new objects, saving them, doing form validation, permission checks, etc. View functions are basically the business logic block, template tags and context processors both provide presentation assistance only. So, there's a few different ways of looking at each of the roles. They are all different and whilst some things can be done in multiple ways there's normally one approach that will feel more natural for each case. That being said, for sufficiently simple situations, whether something is a template tag or part of the view or a context processor might all be more or less the same: don't sweat the small stuff... just pick one and move on with your life. Regards, Malcolm -- If you think nobody cares, try missing a couple of payments. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
