nevroe wrote:
> Eugene -- can you point me to any examples of subviews? In my work,
> I've ended up implementing hacky custom tags, where I take an object,
> and essentially use the custom tag to, in the templatetag code, call
> another view and load the other view.
There is nothing magical about it --- a plain Jane functional
decomposition. Below is the sketch, which is derived from the actual code.
1) The subview (note that I use this term loosely):
def subview(context, ...other_parameters...):
# just like a template tag, I take 'context' instead of 'request'
...
some code here loading objects
...
# actual rendering
t = loader.get_template('subview_template.html')
output = ''
# preserve the state of the context
context.push()
try:
# add local parameters
context['param1'] = param1
context['param2'] = param2
context['param3'] = param3
context['param4'] = param4
context['param5'] = param5
# ready to render
output = t.render(context)
finally:
# pop local stuff out
context.pop()
# I return a string instead of HttpResponse
return output
2) The main view, which assembles subviews:
def main_view(request, ...other_parameters...):
context = RequestContext(request)
dictionary = {}
...
some code here preparing parameters
...
# conditional rendering of a subview
output = '<emph>empty</empth>'
if some_criteria():
# in some case I context.push() here,
# and add subview-specific parameters
output = subview(context, ...other_parameters...)
# if I pushed before, I context.pop() here
# use try/finally for that (see subview code)
dictionary['item1'] = output
...
more code, calculation of other subviews filling dictionary
...
return render_to_response('main_template.html', dictionary,
context_instance=context)
3) The main template:
...html crud...
<!-- Here we'll insert our item1 -->
{{ item1 }}
...more html crud...
4) That's all!
In my code I have separate subviews responsible for generation of
required visual blocks. They are reused by other views, which share
these blocks. A main view is reduce to a simple assembler of required
pieces + its own view-specific content. Subviews use moderately complex
templates. A main view usually uses a simplified template without much
logic in it, and I think this is the Good Thing (tm).
Another consideration was a performance. I don't call subviews, if I
don't need to. Using template tags I precalculated required parameters
and passed them down even if it was decided later not to generate this
part in the template. It increased the complexity and wasted resources.
So I decided to move all complex, conditional (or shared), and
computationally expensive operations in subviews. The results of
subviews can be independently cached, if required to improve the
performance.
Thanks,
Eugene
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
