I've checked the custom tags and the middleware that automatically
registers request object inside the template context, this is all I
need to get the recursive call working. However I wonder why such
functionality isn't there. Probably there is another way to put
content from totally independent components/apps on the same page.
Could someone point me in the right direction?
The overhead of recursive requests is negligible and I will make
custom render tag for it Monday if no other "django way" solution
bubbles up here.
On Aug 7, 8:11 pm, Daniel Roseman <dan...@roseman.org.uk> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
