Re: Recursive request and page layout

[SardarNL]

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

[prabhu S]

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

[SardarNL]

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

[Daniel Roseman]

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
-~--~~~~--~~--~--~---

Recursive request and page layout

[SardarNL]

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.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---