It will be awesome if you can make and open source such a tag. Shouldn't be hard since templates can be evaluated independent of http. If you want something simpler, use iframe and point it to the correct url.
Regards, Prabhu On Aug 8, 12:11 pm, SardarNL <[email protected]> wrote: > 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 <[email protected]> wrote: > > > > > On Aug 7, 5:24 pm, SardarNL <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
