Here's a few things to think about when you start putting lots of logic code into your template.
What happens when your boss comes to you and says he wants the contents of that page in another format like xml or some corporate legacy reporting format? All your extraction logic is buried in the template, which needs to be duplicated in the xslt template, a real violation of DRY and a maintenance headache. Much easier to prepare the data in the view and feed it to a different template based on a view argument. Django views can also be thought of as relational database views. Database views are sometimes used for security, so that certain columns of a table are not returned in a query if a specific user is not allowed to view them. If you start passing all data from a query into a template and let the template pick whatever data it needs to enforce this form of security, you're removing this security protection from the view. In large organizations where programming and design are separated, this protection can be easily violated through malice, neglect or ignorance. When I code, my views always decide what data the template is allowed to have, the template decides how it should look. I like the fact that the minimal logic available in Django templates is specifically designed for presentational purposes (such as the date formatter) and efficient data generation (such as loops). Don --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
