Is it considered preferable to use tags to render html, versus using an object method? For example, in the admin app I see that the following tag is used like so:
{% result_list cl %} cl is an object, and I'm wondering what is the advantage of creating result_list as a tag, rather than just using an object method of the cl class and calling it like this: {{ cl.result_list }} Is the reason for this to put a better separation between the rendering code (ie, the view in MVC) and the business logic? I can see that if one references only context variables and tags from the html templates, it resricts the scope of what your html can do, making it easier to maintain and keeping the rendering logic more encapsulated. So that does seem like a good thing. At the same time, once one has a lot of tags, those tags seem to have little OO structure and are hard to "black box" via encapsulation. For example, if you look at admin_list.py in the admin app, it contains a bunch of tags that all access data from the ChangeList object, yet it is difficult to really understand what is going on without studying that code in great detail. This seems like sort of poor encapsulation to me. On the flip side, it seems that one could create a bunch of object methods that render html by calling render_to_string() on various html templates and use these object methods instead of template tags. For example, in the admin app, one could have additional ChangeList methods that render the result list and call those methds rather than the tags in admin_list.py (obviously much of the code would be teh same, but the interface would be slightly different). This has a nice OO feel, but I can see this is basically making the business logic (my OO classes) responsible for rendering, which is perhaps a bad thing from the point of view of keeping rendering code separate from business logic. (There is the practical aspect that one needs to access context, and the tags gives you access to that - but I'm sure there would be some way to do that from a class method as well.) Is it true that there is a bit of an inherent conflict between keeping business logic and rendering code separate, and at the same time having object encapsulation where an object does everything for itself (ie, renders itself)? Is it considered best-practice to sacrifice OO in this case in order to keep the rendering code separate from the business logic? Just curious if others have encountered this and what the "best practice" philosophy is here. Margie -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.