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.
