Re: Accessing Request Object in Form Definition

[Chris Kavanagh]

Thank you so much, James. . .I greatly appreciate you taking the time to 
answer!

On Tuesday, February 23, 2016 at 1:50:57 AM UTC-5, James Schneider wrote:
>
> On Mon, Feb 22, 2016 at 10:23 PM, Chris Kavanagh  > wrote:
>
>> To possibly answer my own question, thinking out loud, we have to 
>> override the Form Constructor so we can pass in the Request from the view 
>> when instantiating the Form?
>>
>
> You beat me to it. Yes, you would need to override __init__() to include 
> the request in to your form class. Be sure to keep it out of your 
> args/kwargs that are passed on to your super() call, though, as it will 
> confuse the parent form class (if I remember correctly when I did the same 
> thing). If you are using CBV's, that you'll need to override get_form() as 
> well in order to return the form with the self.request as one of the 
> arguments being passed in.
>
> -James
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0ccd7441-900f-474d-ab26-4e2e737c343c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accessing Request Object in Form Definition

[James Schneider]

On Mon, Feb 22, 2016 at 10:23 PM, Chris Kavanagh  wrote:

> To possibly answer my own question, thinking out loud, we have to override
> the Form Constructor so we can pass in the Request from the view when
> instantiating the Form?
>

You beat me to it. Yes, you would need to override __init__() to include
the request in to your form class. Be sure to keep it out of your
args/kwargs that are passed on to your super() call, though, as it will
confuse the parent form class (if I remember correctly when I did the same
thing). If you are using CBV's, that you'll need to override get_form() as
well in order to return the form with the self.request as one of the
arguments being passed in.

-James

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciWRm5muqDY75_tCh%2BfroAsT70iAYW%2BCVL__aPAtVoQ4wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accessing Request Object in Form Definition

[Chris Kavanagh]

To possibly answer my own question, thinking out loud, we have to override 
the Form Constructor so we can pass in the Request from the view when 
instantiating the Form?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/db26c4d0-edd0-4e0e-8af1-257627a6b0b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Accessing Request Object in Form Definition

[Chris Kavanagh]

I'm trying to understand how overriding the Constructor of a Form 
(forms.Form or model.Models) allows you to access the Request Object?  How 
does overriding __init__ allow one access to the Request?
I've looked at BaseForm and don't see the Request in the Constructor. So, I 
don't get it. I thought the Request Object could only be accessed in Views, 
basically. Any help is greatly appreciated, or a point in the right 
direction.

Ex:

class MyForm(forms.Form):

def __init__(self, request, *args, **kwargs):

self._my_request = request
super(MyForm, self).__init__(*args, **kwargs)



PS: It;s been years since I've used this group, if I've not posted the 
question, my apologies.




-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5e6430d8-f6ce-4a15-b2b4-0ecf7464e6b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accessing request object

[Salvatore DI DIO]

I understand now,

Thank you very much Altus and Collin


2014-09-23 1:30 GMT+02:00 alTus :

> Collin said you can attach your `request` object to the form object
> somewhere in your view. After that you will be able to use in anywhere in
> methods.
> Also you can consider adding request parameter explicitly to your
> __init__ method and then passing it to `restrictQuery`.
>
> PS. restrictQuery should be named restrict_query according to python
> style guide.
>
> воскресенье, 21 сентября 2014 г., 15:38:23 UTC+4 пользователь Salvatore DI
> DIO написал:
>
>> Hello,
>>
>> Is it possible to access request object in 'helpers.py' file ?
>> Ihave tried 'crequest'  (from crequest.middleware import
>> CrequestMiddleware)
>> without luck.
>>
>>
>> class AdminField(object):
>> def __init__(self, form, field, is_first):
>> self.field = form[field]  # A django.forms.BoundField instance
>> self.is_first = is_first  # Whether this field is first on the
>> line
>> self.is_checkbox = isinstance(self.field.field.widget,
>> forms.CheckboxInput)
>> if (field == 'albums'):
>> self.restrictQuery()
>>
>> def restrictQuery(self):
>> from portfolio.models import Album
>> #qs =  Album.objects.filter(title='Famille')
>> qs =  Album.objects.all()
>> self.field.field.queryset = qs
>>
>>
>> I would like to access 'request.user' in 'restrictQuery
>>
>> Regards
>>
>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/B4m9ki4hqp8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/033933b4-fb7b-46ca-bdf5-ada2011cb902%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAPj0iHuNFTQeqtu8dr56XLpviBwC1rmuWZxWe9FOm69aw206mA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accessing request object

[alTus]

Collin said you can attach your `request` object to the form object 
somewhere in your view. After that you will be able to use in anywhere in 
methods.
Also you can consider adding request parameter explicitly to your __init__ 
method and then passing it to `restrictQuery`.

PS. restrictQuery should be named restrict_query according to python style 
guide.

воскресенье, 21 сентября 2014 г., 15:38:23 UTC+4 пользователь Salvatore DI 
DIO написал:
>
> Hello,
>
> Is it possible to access request object in 'helpers.py' file ?
> Ihave tried 'crequest'  (from crequest.middleware import 
> CrequestMiddleware)
> without luck.
>
>
> class AdminField(object):
> def __init__(self, form, field, is_first):
> self.field = form[field]  # A django.forms.BoundField instance
> self.is_first = is_first  # Whether this field is first on the line
> self.is_checkbox = isinstance(self.field.field.widget, 
> forms.CheckboxInput)
> if (field == 'albums'):
> self.restrictQuery()
>
> def restrictQuery(self):
> from portfolio.models import Album
> #qs =  Album.objects.filter(title='Famille')
> qs =  Album.objects.all()
> self.field.field.queryset = qs
>
>
> I would like to access 'request.user' in 'restrictQuery
>
> Regards
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/033933b4-fb7b-46ca-bdf5-ada2011cb902%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accessing request object

[Salvatore DI DIO]

Excuse me Collin, I don't understang what you are meaning ...

Le lundi 22 septembre 2014 17:46:41 UTC+2, Collin Anderson a écrit :
>
> Can you attach the request to `form.request`?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b024d07f-b718-4d7b-93ac-9a382b8cec36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accessing request object

[Collin Anderson]

Can you attach the request to `form.request`?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0d1b789e-2832-4920-9dac-853078345384%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Accessing request object

[Salvatore DI DIO]

Hello,

Is it possible to access request object in 'helpers.py' file ?
Ihave tried 'crequest'  (from crequest.middleware import CrequestMiddleware)
without luck.


class AdminField(object):
def __init__(self, form, field, is_first):
self.field = form[field]  # A django.forms.BoundField instance
self.is_first = is_first  # Whether this field is first on the line
self.is_checkbox = isinstance(self.field.field.widget, 
forms.CheckboxInput)
if (field == 'albums'):
self.restrictQuery()

def restrictQuery(self):
from portfolio.models import Album
#qs =  Album.objects.filter(title='Famille')
qs =  Album.objects.all()
self.field.field.queryset = qs


I would like to access 'request.user' in 'restrictQuery

Regards


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/73622288-ada3-4555-920c-2d90e8624536%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accessing request object in templates

[annacoder]

On Jan 4, 7:34 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2008-01-03 at 23:10 +0530, venkata subramanian wrote:
> > Hi,
> >  I had a problem recently.
> >  To access the request object in all of my templates.
> >  The solution I got surprised me. It involved explicitly passing on
> > the request object from the views.
> >  (Example, to pass a RequestContext object as a context_instance
> > parameter in render_to_response method).
>
> > It surprised me because since request object is available to every
> > view, why should the request
> > object not be accessible in all templates by default?
>
> Using RequestContext means that all the context processors are run. This
> overhead isn't needed in all cases. So Django provides a way to render a
> temlpate without the context processors being run (if you use Context())
> and with the context processors being run (if you use RequestContext()).
> If we always did the second thing, there would be no way to do the first
> thing.
>
> It's trivial (not just easy, completely trivial) to write your own
> version of render_to_response() if you always want to use
> RequestContext. The entire function is two lines long. Of course, you'll
> have to pass it the 'request' instance every time, so that it's
> initialised correctly, but that's the cost of wanting request-related
> stuff.
>
I agree it is trivial. Also, after looking around, and asking people,
I find that many people do (independently) write that two line
function.
(And I guess, each of those must have done some looking around and
asking people themselves
to come to that two line function).

Example:   http://www.djangosnippets.org/snippets/3/

If it is more like an idiom, then is why is it not a built in shortcut
function?
 1. It will prevent many people from writing that same 2 line code.
 2. While reading the documentation as a newbie, it will become
evidently clear about how one
 can pass the request object to the template.


> Yes, we could have the default being the reverse of what it is now, but
> the arguments each way are pretty easily balanced. Sometimes you always
> want to use RequestContext, sometimes you don't need it at all. So
> there's no strong reason to change things when it's so easy to write
> your won alternative shortcut.
>
> Regards,
> Malcolm
>

Thanks a lot for your explanation.
Its much clearer to me now.

> --
> The early bird may get the worm, but the second mouse gets the 
> cheese.http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Accessing request object in templates

[annacoder]

Thanks a lot for your detailed answer.

In Zen terms, I am 'enlightened' now ;)

On Jan 4, 1:07 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> On Jan 3, 2008 2:33 PM, annacoder <[EMAIL PROTECTED]> wrote:
>
>
>
> > I understand *how* it is done.
>
> > But, my question was not related to the how part.
>
> Here's a quick rundown of the "why".
>
> Templates aren't triggered by HTTP requests like views are. Instead,
> they're rendered inside views, which *are* triggered by HTTP requests.
> Since the request triggers the view, it makes sense for the view to
> receive the request object. Since templates are rendered by views, it
> makes sense for templates to receive whatever the view sends them, and
> nothing more. This is a design decision for at least a few reasons.
>
> 1) It allows templates to be more easily used outside of views, for
> things like rendering reports about the content in the database or
> anything else you might imagine.
>
> 2) It provides a clean separation of concerns. Views deal with
> requests and responses, templates deal with variables and output
> formatting. And since the view's the one "in charge" of the
> relationship, it should be up to the view to decide what the template
> gets access to.
>
> 3) The request would have to come from somewhere. Either you provide
> it to the template explicitly (usually via RequestContext) or the
> template code has to reach into Python's internal runtime data to
> magically retrieve the request from the view. This process is very bad
> because it:
>
>   * isn't very fast
>   * is very very ugly
>   * is far from foolproof
>   * makes the view feel like Rob Lowe at the end of Wayne's World (if
> you haven't seen it, trust me, it's not a good thing)
>
> 4) If you're more philosophical, this is also covered very clearly in
> Tim Peter's Zen of Python: "Explicit is better than implicit." You
> explicitly send the request to the template, so it's a Good Thing.
>
> -Gul
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Accessing request object in templates

[Malcolm Tredinnick]

On Thu, 2008-01-03 at 23:10 +0530, venkata subramanian wrote:
> Hi,
>  I had a problem recently.
>  To access the request object in all of my templates.
>  The solution I got surprised me. It involved explicitly passing on
> the request object from the views.
>  (Example, to pass a RequestContext object as a context_instance
> parameter in render_to_response method).
> 
> It surprised me because since request object is available to every
> view, why should the request
> object not be accessible in all templates by default?

Using RequestContext means that all the context processors are run. This
overhead isn't needed in all cases. So Django provides a way to render a
temlpate without the context processors being run (if you use Context())
and with the context processors being run (if you use RequestContext()).
If we always did the second thing, there would be no way to do the first
thing.

It's trivial (not just easy, completely trivial) to write your own
version of render_to_response() if you always want to use
RequestContext. The entire function is two lines long. Of course, you'll
have to pass it the 'request' instance every time, so that it's
initialised correctly, but that's the cost of wanting request-related
stuff.

Yes, we could have the default being the reverse of what it is now, but
the arguments each way are pretty easily balanced. Sometimes you always
want to use RequestContext, sometimes you don't need it at all. So
there's no strong reason to change things when it's so easy to write
your won alternative shortcut.

Regards,
Malcolm

-- 
The early bird may get the worm, but the second mouse gets the cheese. 
http://www.pointy-stick.com/blog/


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Accessing request object in templates

[Marty Alchin]

On Jan 3, 2008 2:33 PM, annacoder <[EMAIL PROTECTED]> wrote:
>
> I understand *how* it is done.
>
> But, my question was not related to the how part.

Here's a quick rundown of the "why".

Templates aren't triggered by HTTP requests like views are. Instead,
they're rendered inside views, which *are* triggered by HTTP requests.
Since the request triggers the view, it makes sense for the view to
receive the request object. Since templates are rendered by views, it
makes sense for templates to receive whatever the view sends them, and
nothing more. This is a design decision for at least a few reasons.

1) It allows templates to be more easily used outside of views, for
things like rendering reports about the content in the database or
anything else you might imagine.

2) It provides a clean separation of concerns. Views deal with
requests and responses, templates deal with variables and output
formatting. And since the view's the one "in charge" of the
relationship, it should be up to the view to decide what the template
gets access to.

3) The request would have to come from somewhere. Either you provide
it to the template explicitly (usually via RequestContext) or the
template code has to reach into Python's internal runtime data to
magically retrieve the request from the view. This process is very bad
because it:

  * isn't very fast
  * is very very ugly
  * is far from foolproof
  * makes the view feel like Rob Lowe at the end of Wayne's World (if
you haven't seen it, trust me, it's not a good thing)

4) If you're more philosophical, this is also covered very clearly in
Tim Peter's Zen of Python: "Explicit is better than implicit." You
explicitly send the request to the template, so it's a Good Thing.

-Gul

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Accessing request object in templates

[annacoder]

I understand *how* it is done.

But, my question was not related to the how part.


On Jan 4, 12:17 am, Ariel Calzada <[EMAIL PROTECTED]> wrote:
> venkata subramanian wrote:
> > Hi,
> >  I had a problem recently.
> >  To access the request object in all of my templates.
> >  The solution I got surprised me. It involved explicitly passing on
> > the request object from the views.
> >  (Example, to pass a RequestContext object as a context_instance
> > parameter in render_to_response method).
>
> > It surprised me because since request object is available to every
> > view, why should the request
> > object not be accessible in all templates by default?
>
> > I am just eager to understand this design decision.
>
> > Thanks.
>
> You can do it
>
> in settings.py add:
>
> TEMPLATE_CONTEXT_PROCESSORS = (
>  'django.core.context_processors.auth',
> 'django.core.context_processors.request',
> )
>
> and in every view import:
>
> from django.template  import RequestContext
>
> adn finally when you make a render to response:
>
> return render_to_response ( "TEMPLATEFILE",   {},  context_instance =
> RequestContext ( request ),  )
>
> ARIEL ( 000PaRaDoX000 )
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Accessing request object in templates

[annacoder]

Can you explain what is the security issue?


On Jan 3, 10:58 pm, Sam Lai <[EMAIL PROTECTED]> wrote:
> Security maybe?
>
> Not sure, but if you add django.core.context_processors.request to
> your TEMPLATE_CONTEXT_PROCESSORS list in settings.py, you won't have
> to explicitly add the request object in every view. You still have to
> pass a RequestContext object to the render_to_response method, but you
> should be doing that anyway if you plan on using any context
> processors (which are useful for other things like users), because
> otherwise, none of the context processors get added.
>
> It would be easier if a RequestContext object gets passed by the
> render_to_response method automatically, but that isn't to hard to
> change by creating a new method.
>
> Sam
>
> On Jan 4, 1:40 am, "venkata subramanian"
>
> <[EMAIL PROTECTED]> wrote:
> > Hi,
> >  I had a problem recently.
> >  To access the request object in all of my templates.
> >  The solution I got surprised me. It involved explicitly passing on
> > the request object from the views.
> >  (Example, to pass a RequestContext object as a context_instance
> > parameter in render_to_response method).
>
> > It surprised me because since request object is available to every
> > view, why should the request
> > object not be accessible in all templates by default?
>
> > I am just eager to understand this design decision.
>
> > Thanks.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Accessing request object in templates

[Ariel Calzada]

venkata subramanian wrote:
> Hi,
>  I had a problem recently.
>  To access the request object in all of my templates.
>  The solution I got surprised me. It involved explicitly passing on
> the request object from the views.
>  (Example, to pass a RequestContext object as a context_instance
> parameter in render_to_response method).
>
> It surprised me because since request object is available to every
> view, why should the request
> object not be accessible in all templates by default?
>
> I am just eager to understand this design decision.
>
> Thanks.
>
> >
>
>   
You can do it

in settings.py add:

TEMPLATE_CONTEXT_PROCESSORS = (
 'django.core.context_processors.auth',
'django.core.context_processors.request',
)

and in every view import:

from django.template  import RequestContext

adn finally when you make a render to response:

return render_to_response ( "TEMPLATEFILE",   {},  context_instance = 
RequestContext ( request ),  )

ARIEL ( 000PaRaDoX000 )






--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Accessing request object in templates

[Alex Koshelev]

No. RequestContext instance used to handle context processors. It
doesn't pass request instance to the context. Request instance passed
to template context only by "django.core.context_processors.request"
if its installed.

On 3 янв, 20:40, "venkata subramanian" <[EMAIL PROTECTED]>
wrote:
> Hi,
>  I had a problem recently.
>  To access the request object in all of my templates.
>  The solution I got surprised me. It involved explicitly passing on
> the request object from the views.
>  (Example, to pass a RequestContext object as a context_instance
> parameter in render_to_response method).
>
> It surprised me because since request object is available to every
> view, why should the request
> object not be accessible in all templates by default?
>
> I am just eager to understand this design decision.
>
> Thanks.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Accessing request object in templates

[Sam Lai]

Security maybe?

Not sure, but if you add django.core.context_processors.request to
your TEMPLATE_CONTEXT_PROCESSORS list in settings.py, you won't have
to explicitly add the request object in every view. You still have to
pass a RequestContext object to the render_to_response method, but you
should be doing that anyway if you plan on using any context
processors (which are useful for other things like users), because
otherwise, none of the context processors get added.

It would be easier if a RequestContext object gets passed by the
render_to_response method automatically, but that isn't to hard to
change by creating a new method.

Sam

On Jan 4, 1:40 am, "venkata subramanian"
<[EMAIL PROTECTED]> wrote:
> Hi,
>  I had a problem recently.
>  To access the request object in all of my templates.
>  The solution I got surprised me. It involved explicitly passing on
> the request object from the views.
>  (Example, to pass a RequestContext object as a context_instance
> parameter in render_to_response method).
>
> It surprised me because since request object is available to every
> view, why should the request
> object not be accessible in all templates by default?
>
> I am just eager to understand this design decision.
>
> Thanks.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Accessing request object in templates

[venkata subramanian]

Hi,
 I had a problem recently.
 To access the request object in all of my templates.
 The solution I got surprised me. It involved explicitly passing on
the request object from the views.
 (Example, to pass a RequestContext object as a context_instance
parameter in render_to_response method).

It surprised me because since request object is available to every
view, why should the request
object not be accessible in all templates by default?

I am just eager to understand this design decision.

Thanks.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---