Re: Recursive request and page layout
Django solution found - template tags. The way how django discovers the tags makes it easy to publish them. The applications just exports the content as tags and anyone can use it. If request object is needed (for cookie etc) then django.core.context_processors.request template content processor can provide it. Thanks to everybody and django-* projects where from I've discovered the power of template tags. On Aug 9, 11:24 am, prabhu S wrote: > 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 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 wrote: > > > > On Aug 7, 5:24 pm, SardarNL 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 -~--~~~~--~~--~--~---
Re: Recursive request and page layout
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 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 wrote: > > > > > On Aug 7, 5:24 pm, SardarNL 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 -~--~~~~--~~--~--~---
Re: Recursive request and page layout
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 wrote: > On Aug 7, 5:24 pm, SardarNL 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 -~--~~~~--~~--~--~---
Re: Recursive request and page layout
On Aug 7, 5:24 pm, SardarNL 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 -~--~~~~--~~--~--~---