On Aug 7, 5:24 pm, SardarNL <ja.d...@gmail.com> wrote:
> Hi Folks
>
> Here is the problem, we have some pages that don't contain any
> content, but rather layout the blocks which are served by other views.
> Extending the template and overriding some blocks is not a solution,
> because there are many unrelated blocks, that can not be rendered by a
> single view.
>
> Naturally I would expect some {% dispatch "/some/path/here" %} tag,
> such that when template is being processed, the tag will issue
> recursive request and will be replaced by obtained content. The tag
> should be able to replace the base template of called view, so the
> header/footer and other markup will not be rendered if view is called
> as a block.
>
> Unfortunately there is no such tag. So my question is: how to give the
> control to independent blocks. The idea is:
>
> - current request is being processed by some view, which knows how
> to fetch only its own content
> - the designer may want to add other content/block, totally
> unrelated to current request, for example a poll/banner/menu etc.
> - the block needs to be served by some view because there database
> fetch is needed along other processing. So simple include of a
> template is not a solution. Fetching all the content within the top-
> most view isn't a solution because the block can be used on many
> places.
>
> That is the reason why this should be implemented as recursive call,
> such that the block-view will not even know it is being called as a
> block and will simply render the content. Of course in real situation
> the view still needs to know it is being called as a block, such that
> more simplistic templates may be used.
>
> Please explain what is the django way and how would you solve this,
> maybe I'm digging in totally wrong direction.
Including blocks on a page is what custom template tags are for. See
here:
http://docs.djangoproject.com/en/dev/howto/custom-template-tags/
particularly the section on 'inclusion tags'.
That's not exactly what you asked for in terms of recursive views, but
is probably better as it has less overhead - calling a view
recursively would involve instantiating an HttpResponse object each
time, then extracting the content and throwing the object away.
--
DR.
--~--~---------~--~----~------------~-------~--~----~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
