Re: Why the next parameter does NOT show up in request object?

[Christian Seberino]

Andreas

Thanks so much.  This was very helpful.  For what its worth, the keyword on
the Form class
seems to be "initial" rather than "initial_data" now.  Thanks again!
Awesome stuff!

cs


> def log_in(request):
> if request.method == "POST":
> form = pollster.forms.LogInForm(request.POST)
> if form.is_valid():
> username = form.cleaned_data["username"].lower()
> password = form.cleaned_data["password"]
> next = form.cleaned_data('next')
> reply= django.shortcuts.redirect(next)
> user = AUTH(username = username,
> password = password)
> if user:
> django.contrib.auth.login(request, user)
> else:
> reply = django.shortcuts.render(request,
> "log_in.html",
> {"form" : form})
> else:
> form  = pollster.forms.LogInForm(initial_data={'next':
> request.GET.get('next')})
> reply = django.shortcuts.render(request,
> "log_in.html",
> {"form" : form})
>
> return reply
>
> So I have updated the code both for the get and post. The get populates
> the initial data for the form (the next parameter). You of course need to
> add the next field to your form code.
>
> Then in the template you can add the following:
>
> 
> 
>  value="{{form.next.value}}">
> Username:
>
> {{form.username}}
>
> Password:
>
> {{form.password}}
>
> 
>
> {% csrf_token %}
> 
> 
>
> This way your form will include the posted next data and you can get the
> next field from the login 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAG5-5iJ9hKQaWuQM2iF4pPzRuXntcNfYKonzAFqHmGUvAz6QCQ%40mail.gmail.com.

Re: Why the next parameter does NOT show up in request object?

[Andréas Kühne]

Hi,

There are 2 errors in your code.

First, when you do a request to the page, it is a get (you go from another
page to this page). In this case the next parameter is there and you
receive it in the "else" part of your view function (because the request is
a get). So you have the next parameter as a get parameter in that case.
Second, when you submit the form, it is submitted via a post. In this case
the get parameters are filled out, but the POST part of the request is. So
you populate your form with the information sent via a POST, and you do
this here:
form = pollster.forms.LogInForm(request.POST)

So the GET part of the request is empty in this case, because the request
is a POST.

What you need to do is get the parameter from the request when you populate
the form and then send it to the template:
def log_in(request):
if request.method == "POST":
form = pollster.forms.LogInForm(request.POST)
if form.is_valid():
username = form.cleaned_data["username"].lower()
password = form.cleaned_data["password"]
next = form.cleaned_data('next')
reply= django.shortcuts.redirect(next)
user = AUTH(username = username,
password = password)
if user:
django.contrib.auth.login(request, user)
else:
reply = django.shortcuts.render(request,
"log_in.html",
{"form" : form})
else:
form  = pollster.forms.LogInForm(initial_data={'next':
request.GET.get('next')})
reply = django.shortcuts.render(request,
"log_in.html",
{"form" : form})

return reply

So I have updated the code both for the get and post. The get populates the
initial data for the form (the next parameter). You of course need to add
the next field to your form code.

Then in the template you can add the following:




Username:

{{form.username}}

Password:

{{form.password}}



{% csrf_token %}



This way your form will include the posted next data and you can get the
next field from the login form.

Regards,

Andréas


Den fre 1 nov. 2019 kl 19:10 skrev Christian Seberino :

> I can see the next parameter hanging off the URL of my log_in page.
> However, I cannot *read* it in my view code.  The next parameter does NOT
> get
> passed to my Python code...Why not?  Is my form action = "." the problem
> below?
>
> Here is the traceback.
>
> https://dpaste.de/H7KU
>
> Here is my log in page...
>
>
> def log_in(request):
> if request.method == "POST":
> form = pollster.forms.LogInForm(request.POST)
> if form.is_valid():
> username = form.cleaned_data["username"].lower()
> password = form.cleaned_data["password"]
> next = request.GET.get("next")
> reply= django.shortcuts.redirect(next)
> user = AUTH(username = username,
> password = password)
> if user:
> django.contrib.auth.login(request, user)
> else:
> reply = django.shortcuts.render(request,
> "log_in.html",
> {"form" : form})
> else:
> form  = pollster.forms.LogInForm()
> reply = django.shortcuts.render(request,
> "log_in.html",
> {"form" : form})
>
> return reply
>
> Here is my template...
>
> 
> 
> 
> Pollster
>href = "/static/base.css"
>   rel  = "stylesheet">
>http-equiv = "content-type">
> 
> 
>
> 
> 
> Username:
>
> {{form.username}}
>
> Password:
>
> {{form.password}}
>
> 
>
> {% csrf_token %}
> 
> 
>
> 
> 
>
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/bed8ec66-572d-4306-a496-edf9b69142bb%40googlegroups.com
> 

Why the next parameter does NOT show up in request object?

[Christian Seberino]

I can see the next parameter hanging off the URL of my log_in page.
However, I cannot *read* it in my view code.  The next parameter does NOT 
get 
passed to my Python code...Why not?  Is my form action = "." the problem 
below?

Here is the traceback.

https://dpaste.de/H7KU

Here is my log in page...


def log_in(request):
if request.method == "POST":
form = pollster.forms.LogInForm(request.POST)
if form.is_valid():
username = form.cleaned_data["username"].lower()
password = form.cleaned_data["password"]
next = request.GET.get("next")
reply= django.shortcuts.redirect(next)
user = AUTH(username = username,
password = password)
if user:
django.contrib.auth.login(request, user)
else:
reply = django.shortcuts.render(request,
"log_in.html",
{"form" : form})
else:
form  = pollster.forms.LogInForm()
reply = django.shortcuts.render(request,
"log_in.html",
{"form" : form})

return reply

Here is my template...




Pollster







Username:

{{form.username}}

Password:

{{form.password}}



{% csrf_token %}








-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/bed8ec66-572d-4306-a496-edf9b69142bb%40googlegroups.com.

Using the request object in the forms.py file

[Kayode Oladipo]

Top of the morning to you.
I'm trying to build a kinda-sorta e-voting system where there are positions
and certain aspirants vie for said positions.
Now I have a form setup with a radio Choice() widget, but I want the
choices dict [CHOICES] to be dynamic per page, that is, the list only
contains the aspirant going for that particular position.

I intend doing this by gettting the urls and comparing them with the
absolute url of each aspirant. But I have trouble doing this, I can't seem
to succesfully get the request object to work.

I'll appreciate any help.

Cheers,
'Kayode

My forms.py
--forms.py-

from django import formsfrom django.http import Http404, HttpRequest
from .models import Aspirant, Position

class VotingForm(forms.ModelForm):

def __init__(self, *args, **kwargs):
self.request = kwargs.pop('request', None)
super(VotingForm, self).__init__(*args, **kwargs)

def get_url(self):
_ = []
for post in Position.objects.all():
if self.request.get_full_path() == "/post/pro":
no_ = Position.objects.get(post='PRO')
_.clear()
for i in Aspirant.objects.filter(post=no_):
_.append(tuple([i.name, i.name]))
elif self.request.get_full_path() == "/post/gen-sec":
no_ = Position.objects.get(post='General Secretary')
_.clear()
for i in Aspirant.objects.filter(post=no_):
_.append(tuple([i.name, i.name]))
elif self.request.get_full_path() == "/post/vp-admin":
no_ = Position.objects.get(post='Vice President (Admin)')
_.clear()
for i in Aspirant.objects.filter(post=no_):
_.append(tuple([i.name, i.name]))
elif self.request.get_full_path() == "/post/vp-editorial":
no_ = Position.objects.get(post='Vice President (Editorial)')
_.clear()
for i in Aspirant.objects.filter(post=no_):
_.append(tuple([i.name, i.name]))
elif self.request.get_full_path() == "/post/president":
no_ = Position.objects.get(post='President')
_.clear()
for i in Aspirant.objects.filter(post=no_):
_.append(tuple([i.name, i.name]))

return _

aspirants = forms.ChoiceField(choices=CHOICES, widget=forms.RadioSelect)

class Meta:
model = Aspirant
fields = ['aspirants']

-- 
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%2BARzD9pJP_paCyuH8u1uXtmJctSHAHtmkVmbmsuTC4JEZwXBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[Larry Martell]

Yes, I'm an idiot. I had commented out the middleware when debugging
and forgot to put them back.

On Mon, Feb 29, 2016 at 10:09 AM, knbk <marten.k...@gmail.com> wrote:
> That would happen if the AuthenticationMiddleware hasn't run. In what
> context is request.user missing?
>
> On Monday, February 29, 2016 at 3:54:24 PM UTC+1, larry@gmail.com wrote:
>>
>> So does anyone know why there would be a no user attr? I would expect
>> this:
>>
>> (Pdb) request.user
>> 
>>
>> But I get this:
>>
>> (Pdb) request.user
>> *** AttributeError: 'WSGIRequest' object has no attribute 'user'
>>
>> On Sat, Feb 27, 2016 at 6:31 PM, Larry Martell <larry@gmail.com>
>> wrote:
>> > Yes, you are absolutely correct. Thanks for directing me away from
>> > that red herring. But it seems request.user no longer exists.
>> >
>> > There is code that does this:
>> >
>> > if request.user.is_authenticated():
>> >
>> > which throws:
>> >
>> > AttributeError: "'WSGIRequest' object has no attribute 'user'"
>> >
>> > On Sat, Feb 27, 2016 at 5:48 PM, knbk <marte...@gmail.com> wrote:
>> >> I was referring to the wrong release notes. The rights one can be found
>> >> in
>> >> the 1.8 release notes in the miscellaneous section[1]:
>> >>
>> >>> HttpRequest now has a simplified repr (e.g. > >>> '/somepath/'>). This won’t change the behavior of
>> >>> theSafeExceptionReporterFilter class.
>> >>
>> >>
>> >> Printing the request in your debugger is nothing more than calling repr
>> >> on
>> >> the request and displaying the result. The conclusion is the same: the
>> >> request is not empty, but the string representation of the request has
>> >> changed. This is unrelated to whatever issue you're facing.
>> >>
>> >> [1] https://docs.djangoproject.com/en/1.9/releases/1.8/#miscellaneous
>> >>
>> >> On Saturday, February 27, 2016 at 11:21:18 PM UTC+1,
>> >> larry@gmail.com
>> >> wrote:
>> >>>
>> >>> On Sat, Feb 27, 2016 at 5:14 PM, knbk <marte...@gmail.com> wrote:
>> >>> > The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is
>> >>> > not
>> >>> > an
>> >>> > accurate description of what is actually contained in the request,
>> >>> > and I
>> >>> > doubt it has anything to do with the actual issues you're facing.
>> >>> >
>> >>> > [1]
>> >>> >
>> >>> >
>> >>> > https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting
>> >>>
>> >>> I am printing the request object from the debugger:
>> >>>
>> >>> (Pdb) request
>> >>> 
>> >>>
>> >>> This is not in the debug page. I'm pretty sure it's empty as when I
>> >>> call login(request) I get a blank page with a 200 back.
>> >>>
>> >>> >
>> >>> > On Saturday, February 27, 2016 at 11:09:28 PM UTC+1,
>> >>> > larry@gmail.com
>> >>> > wrote:
>> >>> >>
>> >>> >> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider
>> >>> >> <jrschn...@gmail.com> wrote:
>> >>> >> >
>> >>> >> > On Feb 27, 2016 1:55 PM, "Larry Martell" <larry@gmail.com>
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> Anyone have any insights on this? Is there anything special I
>> >>> >> >> need
>> >>> >> >> to
>> >>> >> >> do get the request structure? The way this 1.9 site is now, it
>> >>> >> >> doesn't
>> >>> >> >> work at all because the request structure is not getting passed
>> >>> >> >> in.
>> >>> >> >>
>> >>> >> >
>> >>> >> > I'd be most suspicious of middle ware not handling the request
>> >>> >> > correctly.
>> >>> >>
>> >>> >> I tried removing all the middleware, but I got the same result.
>> >>> >> This
>> >>> >> is the middlew

Re: empty request object

[knbk]

That would happen if the AuthenticationMiddleware hasn't run. In what 
context is request.user missing?

On Monday, February 29, 2016 at 3:54:24 PM UTC+1, larry@gmail.com wrote:
>
> So does anyone know why there would be a no user attr? I would expect 
> this: 
>
> (Pdb) request.user 
>  
>
> But I get this: 
>
> (Pdb) request.user 
> *** AttributeError: 'WSGIRequest' object has no attribute 'user' 
>
> On Sat, Feb 27, 2016 at 6:31 PM, Larry Martell <larry@gmail.com 
> > wrote: 
> > Yes, you are absolutely correct. Thanks for directing me away from 
> > that red herring. But it seems request.user no longer exists. 
> > 
> > There is code that does this: 
> > 
> > if request.user.is_authenticated(): 
> > 
> > which throws: 
> > 
> > AttributeError: "'WSGIRequest' object has no attribute 'user'" 
> > 
> > On Sat, Feb 27, 2016 at 5:48 PM, knbk <marte...@gmail.com > 
> wrote: 
> >> I was referring to the wrong release notes. The rights one can be found 
> in 
> >> the 1.8 release notes in the miscellaneous section[1]: 
> >> 
> >>> HttpRequest now has a simplified repr (e.g.  >>> '/somepath/'>). This won’t change the behavior of 
> >>> theSafeExceptionReporterFilter class. 
> >> 
> >> 
> >> Printing the request in your debugger is nothing more than calling repr 
> on 
> >> the request and displaying the result. The conclusion is the same: the 
> >> request is not empty, but the string representation of the request has 
> >> changed. This is unrelated to whatever issue you're facing. 
> >> 
> >> [1] https://docs.djangoproject.com/en/1.9/releases/1.8/#miscellaneous 
> >> 
> >> On Saturday, February 27, 2016 at 11:21:18 PM UTC+1, 
> larry@gmail.com 
> >> wrote: 
> >>> 
> >>> On Sat, Feb 27, 2016 at 5:14 PM, knbk <marte...@gmail.com> wrote: 
> >>> > The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is 
> not 
> >>> > an 
> >>> > accurate description of what is actually contained in the request, 
> and I 
> >>> > doubt it has anything to do with the actual issues you're facing. 
> >>> > 
> >>> > [1] 
> >>> > 
> >>> > 
> https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting
>  
> >>> 
> >>> I am printing the request object from the debugger: 
> >>> 
> >>> (Pdb) request 
> >>>  
> >>> 
> >>> This is not in the debug page. I'm pretty sure it's empty as when I 
> >>> call login(request) I get a blank page with a 200 back. 
> >>> 
> >>> > 
> >>> > On Saturday, February 27, 2016 at 11:09:28 PM UTC+1, 
> larry@gmail.com 
> >>> > wrote: 
> >>> >> 
> >>> >> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider 
> >>> >> <jrschn...@gmail.com> wrote: 
> >>> >> > 
> >>> >> > On Feb 27, 2016 1:55 PM, "Larry Martell" <larry@gmail.com> 
> wrote: 
> >>> >> >> 
> >>> >> >> Anyone have any insights on this? Is there anything special I 
> need 
> >>> >> >> to 
> >>> >> >> do get the request structure? The way this 1.9 site is now, it 
> >>> >> >> doesn't 
> >>> >> >> work at all because the request structure is not getting passed 
> in. 
> >>> >> >> 
> >>> >> > 
> >>> >> > I'd be most suspicious of middle ware not handling the request 
> >>> >> > correctly. 
> >>> >> 
> >>> >> I tried removing all the middleware, but I got the same result. 
> This 
> >>> >> is the middleware that was in place: 
> >>> >> 
> >>> >> 'django.middleware.security.SecurityMiddleware', 
> >>> >> 'django.contrib.sessions.middleware.SessionMiddleware', 
> >>> >> 'django.middleware.common.CommonMiddleware', 
> >>> >> 'django.middleware.csrf.CsrfViewMiddleware', 
> >>> >> 'django.contrib.auth.middleware.AuthenticationMiddleware', 
> >>> >> 
> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 
> >>> >> 'django.contrib.messages.middleware.MessageMiddleware', 
> >>> >> 'django.middleware.clickjacking.XFrameOptionsMiddleware', 
> >>> >> 'django.middleware.security.SecurityMiddleware', 
> >>> >> 
> >>> >> 
> >>> >> > Have you tried moving to a fresh venv to ensure Django and other 
> >>> >> > packages 
> >>> >> > aren't damaged? 
> >>> >> > 
> >>> >> > Can you replicate the issue on a separate test server? 
> >>> >> 
> >>> >> No, I haven't tried either one yet. I guess I will have to do that, 
> >>> >> but I really would like to just get this setup working. 
>

-- 
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/d9ea027a-4e64-4e43-a5f9-8fe484710574%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[Larry Martell]

So does anyone know why there would be a no user attr? I would expect this:

(Pdb) request.user


But I get this:

(Pdb) request.user
*** AttributeError: 'WSGIRequest' object has no attribute 'user'

On Sat, Feb 27, 2016 at 6:31 PM, Larry Martell <larry.mart...@gmail.com> wrote:
> Yes, you are absolutely correct. Thanks for directing me away from
> that red herring. But it seems request.user no longer exists.
>
> There is code that does this:
>
> if request.user.is_authenticated():
>
> which throws:
>
> AttributeError: "'WSGIRequest' object has no attribute 'user'"
>
> On Sat, Feb 27, 2016 at 5:48 PM, knbk <marten.k...@gmail.com> wrote:
>> I was referring to the wrong release notes. The rights one can be found in
>> the 1.8 release notes in the miscellaneous section[1]:
>>
>>> HttpRequest now has a simplified repr (e.g. >> '/somepath/'>). This won’t change the behavior of
>>> theSafeExceptionReporterFilter class.
>>
>>
>> Printing the request in your debugger is nothing more than calling repr on
>> the request and displaying the result. The conclusion is the same: the
>> request is not empty, but the string representation of the request has
>> changed. This is unrelated to whatever issue you're facing.
>>
>> [1] https://docs.djangoproject.com/en/1.9/releases/1.8/#miscellaneous
>>
>> On Saturday, February 27, 2016 at 11:21:18 PM UTC+1, larry@gmail.com
>> wrote:
>>>
>>> On Sat, Feb 27, 2016 at 5:14 PM, knbk <marte...@gmail.com> wrote:
>>> > The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is not
>>> > an
>>> > accurate description of what is actually contained in the request, and I
>>> > doubt it has anything to do with the actual issues you're facing.
>>> >
>>> > [1]
>>> >
>>> > https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting
>>>
>>> I am printing the request object from the debugger:
>>>
>>> (Pdb) request
>>> 
>>>
>>> This is not in the debug page. I'm pretty sure it's empty as when I
>>> call login(request) I get a blank page with a 200 back.
>>>
>>> >
>>> > On Saturday, February 27, 2016 at 11:09:28 PM UTC+1, larry@gmail.com
>>> > wrote:
>>> >>
>>> >> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider
>>> >> <jrschn...@gmail.com> wrote:
>>> >> >
>>> >> > On Feb 27, 2016 1:55 PM, "Larry Martell" <larry@gmail.com> wrote:
>>> >> >>
>>> >> >> Anyone have any insights on this? Is there anything special I need
>>> >> >> to
>>> >> >> do get the request structure? The way this 1.9 site is now, it
>>> >> >> doesn't
>>> >> >> work at all because the request structure is not getting passed in.
>>> >> >>
>>> >> >
>>> >> > I'd be most suspicious of middle ware not handling the request
>>> >> > correctly.
>>> >>
>>> >> I tried removing all the middleware, but I got the same result. This
>>> >> is the middleware that was in place:
>>> >>
>>> >> 'django.middleware.security.SecurityMiddleware',
>>> >> 'django.contrib.sessions.middleware.SessionMiddleware',
>>> >> 'django.middleware.common.CommonMiddleware',
>>> >> 'django.middleware.csrf.CsrfViewMiddleware',
>>> >> 'django.contrib.auth.middleware.AuthenticationMiddleware',
>>> >> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
>>> >> 'django.contrib.messages.middleware.MessageMiddleware',
>>> >> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
>>> >> 'django.middleware.security.SecurityMiddleware',
>>> >>
>>> >>
>>> >> > Have you tried moving to a fresh venv to ensure Django and other
>>> >> > packages
>>> >> > aren't damaged?
>>> >> >
>>> >> > Can you replicate the issue on a separate test server?
>>> >>
>>> >> No, I haven't tried either one yet. I guess I will have to do that,
>>> >> but I really would like to just get this setup working.

-- 
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/CACwCsY4SPocxSzDrtoij3D9XifLrOsKA7GhJPcFpNajYd_jg%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[Larry Martell]

Yes, you are absolutely correct. Thanks for directing me away from
that red herring. But it seems request.user no longer exists.

There is code that does this:

if request.user.is_authenticated():

which throws:

AttributeError: "'WSGIRequest' object has no attribute 'user'"

On Sat, Feb 27, 2016 at 5:48 PM, knbk <marten.k...@gmail.com> wrote:
> I was referring to the wrong release notes. The rights one can be found in
> the 1.8 release notes in the miscellaneous section[1]:
>
>> HttpRequest now has a simplified repr (e.g. > '/somepath/'>). This won’t change the behavior of
>> theSafeExceptionReporterFilter class.
>
>
> Printing the request in your debugger is nothing more than calling repr on
> the request and displaying the result. The conclusion is the same: the
> request is not empty, but the string representation of the request has
> changed. This is unrelated to whatever issue you're facing.
>
> [1] https://docs.djangoproject.com/en/1.9/releases/1.8/#miscellaneous
>
> On Saturday, February 27, 2016 at 11:21:18 PM UTC+1, larry@gmail.com
> wrote:
>>
>> On Sat, Feb 27, 2016 at 5:14 PM, knbk <marte...@gmail.com> wrote:
>> > The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is not
>> > an
>> > accurate description of what is actually contained in the request, and I
>> > doubt it has anything to do with the actual issues you're facing.
>> >
>> > [1]
>> >
>> > https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting
>>
>> I am printing the request object from the debugger:
>>
>> (Pdb) request
>> 
>>
>> This is not in the debug page. I'm pretty sure it's empty as when I
>> call login(request) I get a blank page with a 200 back.
>>
>> >
>> > On Saturday, February 27, 2016 at 11:09:28 PM UTC+1, larry@gmail.com
>> > wrote:
>> >>
>> >> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider
>> >> <jrschn...@gmail.com> wrote:
>> >> >
>> >> > On Feb 27, 2016 1:55 PM, "Larry Martell" <larry@gmail.com> wrote:
>> >> >>
>> >> >> Anyone have any insights on this? Is there anything special I need
>> >> >> to
>> >> >> do get the request structure? The way this 1.9 site is now, it
>> >> >> doesn't
>> >> >> work at all because the request structure is not getting passed in.
>> >> >>
>> >> >
>> >> > I'd be most suspicious of middle ware not handling the request
>> >> > correctly.
>> >>
>> >> I tried removing all the middleware, but I got the same result. This
>> >> is the middleware that was in place:
>> >>
>> >> 'django.middleware.security.SecurityMiddleware',
>> >> 'django.contrib.sessions.middleware.SessionMiddleware',
>> >> 'django.middleware.common.CommonMiddleware',
>> >> 'django.middleware.csrf.CsrfViewMiddleware',
>> >> 'django.contrib.auth.middleware.AuthenticationMiddleware',
>> >> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
>> >> 'django.contrib.messages.middleware.MessageMiddleware',
>> >> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
>> >> 'django.middleware.security.SecurityMiddleware',
>> >>
>> >>
>> >> > Have you tried moving to a fresh venv to ensure Django and other
>> >> > packages
>> >> > aren't damaged?
>> >> >
>> >> > Can you replicate the issue on a separate test server?
>> >>
>> >> No, I haven't tried either one yet. I guess I will have to do that,
>> >> but I really would like to just get this setup working.

-- 
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/CACwCsY74FYRzT-DKkTT8g80vzx_y5p1T7VJWWwb8i%2B2FfMOr0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[knbk]

I was referring to the wrong release notes. The rights one can be found in 
the 1.8 release notes in the miscellaneous section[1]:

HttpRequest 
> <https://docs.djangoproject.com/en/1.9/ref/request-response/#django.http.HttpRequest>
>  now 
> has a simplified repr (e.g. ). This won’t 
> change the behavior of theSafeExceptionReporterFilter 
> <https://docs.djangoproject.com/en/1.9/howto/error-reporting/#django.views.debug.SafeExceptionReporterFilter>
>  class.


Printing the request in your debugger is nothing more than calling repr on 
the request and displaying the result. The conclusion is the same: the 
request is not empty, but the string representation of the request has 
changed. This is unrelated to whatever issue you're facing. 

[1] https://docs.djangoproject.com/en/1.9/releases/1.8/#miscellaneous

On Saturday, February 27, 2016 at 11:21:18 PM UTC+1, larry@gmail.com 
wrote:
>
> On Sat, Feb 27, 2016 at 5:14 PM, knbk <marte...@gmail.com > 
> wrote: 
> > The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is not 
> an 
> > accurate description of what is actually contained in the request, and I 
> > doubt it has anything to do with the actual issues you're facing. 
> > 
> > [1] 
> > 
> https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting
>  
>
> I am printing the request object from the debugger: 
>
> (Pdb) request 
>  
>
> This is not in the debug page. I'm pretty sure it's empty as when I 
> call login(request) I get a blank page with a 200 back. 
>
> > 
> > On Saturday, February 27, 2016 at 11:09:28 PM UTC+1, larry@gmail.com 
> > wrote: 
> >> 
> >> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider 
> >> <jrschn...@gmail.com> wrote: 
> >> > 
> >> > On Feb 27, 2016 1:55 PM, "Larry Martell" <larry@gmail.com> 
> wrote: 
> >> >> 
> >> >> Anyone have any insights on this? Is there anything special I need 
> to 
> >> >> do get the request structure? The way this 1.9 site is now, it 
> doesn't 
> >> >> work at all because the request structure is not getting passed in. 
> >> >> 
> >> > 
> >> > I'd be most suspicious of middle ware not handling the request 
> >> > correctly. 
> >> 
> >> I tried removing all the middleware, but I got the same result. This 
> >> is the middleware that was in place: 
> >> 
> >> 'django.middleware.security.SecurityMiddleware', 
> >> 'django.contrib.sessions.middleware.SessionMiddleware', 
> >> 'django.middleware.common.CommonMiddleware', 
> >> 'django.middleware.csrf.CsrfViewMiddleware', 
> >> 'django.contrib.auth.middleware.AuthenticationMiddleware', 
> >> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 
> >> 'django.contrib.messages.middleware.MessageMiddleware', 
> >> 'django.middleware.clickjacking.XFrameOptionsMiddleware', 
> >> 'django.middleware.security.SecurityMiddleware', 
> >> 
> >> 
> >> > Have you tried moving to a fresh venv to ensure Django and other 
> >> > packages 
> >> > aren't damaged? 
> >> > 
> >> > Can you replicate the issue on a separate test server? 
> >> 
> >> No, I haven't tried either one yet. I guess I will have to do that, 
> >> but I really would like to just get this setup working. 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > To post to this group, send email to django...@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/890bb238-7980-4b12-bdf2-400379b31ee7%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3e31049c-82cc-4587-bb18-c06e683e65a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[Larry Martell]

On Sat, Feb 27, 2016 at 5:14 PM, knbk <marten.k...@gmail.com> wrote:
> The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is not an
> accurate description of what is actually contained in the request, and I
> doubt it has anything to do with the actual issues you're facing.
>
> [1]
> https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting

I am printing the request object from the debugger:

(Pdb) request


This is not in the debug page. I'm pretty sure it's empty as when I
call login(request) I get a blank page with a 200 back.

>
> On Saturday, February 27, 2016 at 11:09:28 PM UTC+1, larry@gmail.com
> wrote:
>>
>> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider
>> <jrschn...@gmail.com> wrote:
>> >
>> > On Feb 27, 2016 1:55 PM, "Larry Martell" <larry@gmail.com> wrote:
>> >>
>> >> Anyone have any insights on this? Is there anything special I need to
>> >> do get the request structure? The way this 1.9 site is now, it doesn't
>> >> work at all because the request structure is not getting passed in.
>> >>
>> >
>> > I'd be most suspicious of middle ware not handling the request
>> > correctly.
>>
>> I tried removing all the middleware, but I got the same result. This
>> is the middleware that was in place:
>>
>> 'django.middleware.security.SecurityMiddleware',
>> 'django.contrib.sessions.middleware.SessionMiddleware',
>> 'django.middleware.common.CommonMiddleware',
>> 'django.middleware.csrf.CsrfViewMiddleware',
>> 'django.contrib.auth.middleware.AuthenticationMiddleware',
>> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
>> 'django.contrib.messages.middleware.MessageMiddleware',
>> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
>> 'django.middleware.security.SecurityMiddleware',
>>
>>
>> > Have you tried moving to a fresh venv to ensure Django and other
>> > packages
>> > aren't damaged?
>> >
>> > Can you replicate the issue on a separate test server?
>>
>> No, I haven't tried either one yet. I guess I will have to do that,
>> but I really would like to just get this setup working.
>
> --
> 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/890bb238-7980-4b12-bdf2-400379b31ee7%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACwCsY69Sr5aY2fCkOJ-Qa_ffWe1RTg-MwtFPpZm_VSx7FQsiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[knbk]

The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is not an 
accurate description of what is actually contained in the request, and I 
doubt it has anything to do with the actual issues you're facing. 

[1] 
https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting

On Saturday, February 27, 2016 at 11:09:28 PM UTC+1, larry@gmail.com 
wrote:
>
> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider 
>  wrote: 
> > 
> > On Feb 27, 2016 1:55 PM, "Larry Martell"  > wrote: 
> >> 
> >> Anyone have any insights on this? Is there anything special I need to 
> >> do get the request structure? The way this 1.9 site is now, it doesn't 
> >> work at all because the request structure is not getting passed in. 
> >> 
> > 
> > I'd be most suspicious of middle ware not handling the request 
> correctly. 
>
> I tried removing all the middleware, but I got the same result. This 
> is the middleware that was in place: 
>
> 'django.middleware.security.SecurityMiddleware', 
> 'django.contrib.sessions.middleware.SessionMiddleware', 
> 'django.middleware.common.CommonMiddleware', 
> 'django.middleware.csrf.CsrfViewMiddleware', 
> 'django.contrib.auth.middleware.AuthenticationMiddleware', 
> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 
> 'django.contrib.messages.middleware.MessageMiddleware', 
> 'django.middleware.clickjacking.XFrameOptionsMiddleware', 
> 'django.middleware.security.SecurityMiddleware', 
>
>
> > Have you tried moving to a fresh venv to ensure Django and other 
> packages 
> > aren't damaged? 
> > 
> > Can you replicate the issue on a separate test server? 
>
> No, I haven't tried either one yet. I guess I will have to do that, 
> but I really would like to just get this setup working. 
>

-- 
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/890bb238-7980-4b12-bdf2-400379b31ee7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[Larry Martell]

On Sat, Feb 27, 2016 at 5:02 PM, James Schneider
 wrote:
>
> On Feb 27, 2016 1:55 PM, "Larry Martell"  wrote:
>>
>> Anyone have any insights on this? Is there anything special I need to
>> do get the request structure? The way this 1.9 site is now, it doesn't
>> work at all because the request structure is not getting passed in.
>>
>
> I'd be most suspicious of middle ware not handling the request correctly.

I tried removing all the middleware, but I got the same result. This
is the middleware that was in place:

'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.security.SecurityMiddleware',


> Have you tried moving to a fresh venv to ensure Django and other packages
> aren't damaged?
>
> Can you replicate the issue on a separate test server?

No, I haven't tried either one yet. I guess I will have to do that,
but I really would like to just get this setup working.

-- 
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/CACwCsY6TO4odbJW%2BDpGnsKg%3DuiR3j69vYUTNuPrto1Hsu74Rcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[James Schneider]

On Feb 27, 2016 1:55 PM, "Larry Martell"  wrote:
>
> Anyone have any insights on this? Is there anything special I need to
> do get the request structure? The way this 1.9 site is now, it doesn't
> work at all because the request structure is not getting passed in.
>

I'd be most suspicious of middle ware not handling the request correctly.

Have you tried moving to a fresh venv to ensure Django and other packages
aren't damaged?

Can you replicate the issue on a separate test server?

-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%2BciXkpmsxMQop800Hrq2PsG766MX0kNc7ry7kLEcgfMMUEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: empty request object

[Larry Martell]

Anyone have any insights on this? Is there anything special I need to
do get the request structure? The way this 1.9 site is now, it doesn't
work at all because the request structure is not getting passed in.

On Fri, Feb 26, 2016 at 10:09 PM, Larry Martell <larry.mart...@gmail.com> wrote:
> I just integrated a broken django setup, 1.9, python 2.7, nginx,
> uWSGI, RHEL 6. First thing I observed, the views are not receiving
> anything in the request object, e.g.:
>
> (Pdb) print request
> 
>
> Other django systems I've worked with I always get something, e.g.:
>
> (Pdb) print request
>  path:/,
> GET:,
> POST:,
> COOKIES:{'csrftoken': 'ieefjZZJjeif993i4nfmnkZZKJ',
>  'messages': 
> '2f148ec0f66f94740a8ff273dd544b554d28c96c$[["__json_message",0,20,"The
> tool \\"U7316\\" was added successfully."],["__json_message",0,20,"The
> tool \\"U7321\\" was added successfully."],["__json_message",0,20,"The
> tool \\"SEMA116\\" was added
> successfully."],["__json_message",0,20,"The tool \\"U7324\\" was added
> successfully."],["__json_message",0,20,"The tool \\"U7324\\" was
> changed successfully."],["__json_message",0,20,"The tool \\"SEMA116\\"
> was changed successfully."],["__json_message",0,20,"The tool
> \\"U7331\\" was added successfully."],["__json_message",0,20,"The tool
> \\"SEMA207\\" was added successfully."]]',
>  'sessionid': 'xg254b6ki5m981n8oko4n88jnqsj0m1y'},
> META:{'Apple_PubSub_Socket_Render': '/tmp/launch-FIgPyl/Render',
> .
> .
> .
>
> I've never seen this before. What could be causing this? Where would I
> being to look?

-- 
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/CACwCsY7PdxT%3DF3g21LzEyMQ2qAuAB8EjRV9bi5Q5JAo-T6TUeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

empty request object

[Larry Martell]

I just integrated a broken django setup, 1.9, python 2.7, nginx,
uWSGI, RHEL 6. First thing I observed, the views are not receiving
anything in the request object, e.g.:

(Pdb) print request


Other django systems I've worked with I always get something, e.g.:

(Pdb) print request
,
POST:,
COOKIES:{'csrftoken': 'ieefjZZJjeif993i4nfmnkZZKJ',
 'messages': 
'2f148ec0f66f94740a8ff273dd544b554d28c96c$[["__json_message",0,20,"The
tool \\"U7316\\" was added successfully."],["__json_message",0,20,"The
tool \\"U7321\\" was added successfully."],["__json_message",0,20,"The
tool \\"SEMA116\\" was added
successfully."],["__json_message",0,20,"The tool \\"U7324\\" was added
successfully."],["__json_message",0,20,"The tool \\"U7324\\" was
changed successfully."],["__json_message",0,20,"The tool \\"SEMA116\\"
was changed successfully."],["__json_message",0,20,"The tool
\\"U7331\\" was added successfully."],["__json_message",0,20,"The tool
\\"SEMA207\\" was added successfully."]]',
 'sessionid': 'xg254b6ki5m981n8oko4n88jnqsj0m1y'},
META:{'Apple_PubSub_Socket_Render': '/tmp/launch-FIgPyl/Render',
.
.
.

I've never seen this before. What could be causing this? Where would I
being to look?

-- 
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/CACwCsY4aiSYegivhWm4L0b_JiOYkfLfHp81Ser_OGG%3DEpwE67Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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: Using request object in settings.py for custom logging

[Nikunj Badjatya]

Anyone with any idea how to solve this problem?

Thanks in advance.


-- 
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/9fcbf7ab-0076-47c9-8f44-e20d369bdb3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using request object in settings.py for custom logging

[Nikunj Badjatya]

We want to separate out activity per client. This can be useful in many 
ways. Ex. 1) easier debugging of issues. 2) Running some analytics per 
client by looking at his log file. 3) Clients which are no longer a 
customer, their logs can be safely moved to lower storage tiers. etc.
Basically to help in debugging and maintenance of the application.

Thoughts?

On Wednesday, November 25, 2015 at 3:25:26 PM UTC+5:30, Jani Tiainen wrote:
>
> Well sites framework makes possible to do for example multitenancy inside 
> database.
>
> But apparently that is not your case. So why you like to log something per 
> user? What's the real usecase here?
>
> On 25.11.2015 11:45, Nikunj Badjatya wrote:
>
> Thank you for your response. 
> Well our application is single site only. AFAIK, sites framework is useful 
> when your django application serves multiple sites.
> Can you throw some more light on what can be achieved using sites ?
>
> I would like to evaluate all available options.
>
> Thanks.
>
>
> On Tuesday, November 24, 2015 at 4:54:36 PM UTC+5:30, Jani Tiainen wrote: 
>>
>> Hi,
>>
>> Problem is that you quite certainly have different users and several 
>> processess/threads which would lead logging configuration per request. 
>>
>> Is there a reason you don't use something like sites framework to 
>> differentiate clients?
>>
>>
>> On 24.11.2015 12:22, Nikunj Badjatya wrote:
>>
>> Hello,
>>
>> Currently for our application, all django logs are generated and kept at 
>> '/var/log/django.log'
>> We want to have different log files for different clients. i.e. 
>> /var/log/client-1/django.log
>> /var/log/client-2/django.log
>> /var/log/client-3/django.log
>> 
>> 
>>
>> The request object has information about the logged in user (and thus 
>> client). These inturn are stored in a mysql database. 
>>
>> How can django log file path be modified dynamically such that when 
>> client-1 is using the application, his logs go into 
>> '/var/log/client-1/django.log' and so on for other clients ?
>>
>> Using Django 1.6.11 and Python 2.7.
>> 'LOGGING' is defined in settings.py.
>>
>> Thanks.
>>
>> -- 
>> 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...@googlegroups.com.
>> To post to this group, send email to django...@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/c7c7d27a-2804-4993-8bb9-dd9c3fb7eeab%40googlegroups.com>
>> https://groups.google.com/d/
>> msgid/django-users/c7c7d27a-2804-4993-8bb9-dd9c3fb7eeab%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...@googlegroups.com .
> To post to this group, send email to django...@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/4e6070d9-b589-4001-b2c2-c9d3bbe8a4d3%40googlegroups.com?utm_medium=email_source=footer>
> https://groups.google.com/d/msgid/django-users/4e6070d9-b589-4001-b2c2-c9d3bbe8a4d3%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/26fd9de6-5e19-430b-9a79-69c3d9198be5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using request object in settings.py for custom logging

[Jani Tiainen]

Well sites framework makes possible to do for example multitenancy 
inside database.


But apparently that is not your case. So why you like to log something 
per user? What's the real usecase here?


On 25.11.2015 11:45, Nikunj Badjatya wrote:

Thank you for your response.
Well our application is single site only. AFAIK, sites framework is 
useful when your django application serves multiple sites.

Can you throw some more light on what can be achieved using sites ?

I would like to evaluate all available options.

Thanks.


On Tuesday, November 24, 2015 at 4:54:36 PM UTC+5:30, Jani Tiainen wrote:

Hi,

Problem is that you quite certainly have different users and
several processess/threads which would lead logging configuration
per request.

Is there a reason you don't use something like sites framework to
differentiate clients?


On 24.11.2015 12:22, Nikunj Badjatya wrote:

Hello,

Currently for our application, all django logs are generated and
kept at '/var/log/django.log'
We want to have different log files for different clients. i.e.
/var/log/client-1/django.log
/var/log/client-2/django.log
/var/log/client-3/django.log



The request object has information about the logged in user (and
thus client). These inturn are stored in a mysql database.

How can django log file path be modified dynamically such that
when client-1 is using the application, his logs go into
'/var/log/client-1/django.log' and so on for other clients ?

Using Django 1.6.11 and Python 2.7.
'LOGGING' is defined in settings.py.

Thanks.

-- 
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...@googlegroups.com .
To post to this group, send email to django...@googlegroups.com
.
Visit this group at http://groups.google.com/group/django-users
<http://groups.google.com/group/django-users>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-users/c7c7d27a-2804-4993-8bb9-dd9c3fb7eeab%40googlegroups.com

<https://groups.google.com/d/msgid/django-users/c7c7d27a-2804-4993-8bb9-dd9c3fb7eeab%40googlegroups.com>.
For more options, visit https://groups.google.com/d/optout
<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 
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com 
<mailto: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/4e6070d9-b589-4001-b2c2-c9d3bbe8a4d3%40googlegroups.com 
<https://groups.google.com/d/msgid/django-users/4e6070d9-b589-4001-b2c2-c9d3bbe8a4d3%40googlegroups.com?utm_medium=email_source=footer>.

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/56558556.7010309%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using request object in settings.py for custom logging

[Nikunj Badjatya]

Thank you for your response.
Well our application is single site only. AFAIK, sites framework is useful 
when your django application serves multiple sites.
Can you throw some more light on what can be achieved using sites ?

I would like to evaluate all available options.

Thanks.


On Tuesday, November 24, 2015 at 4:54:36 PM UTC+5:30, Jani Tiainen wrote:
>
> Hi,
>
> Problem is that you quite certainly have different users and several 
> processess/threads which would lead logging configuration per request. 
>
> Is there a reason you don't use something like sites framework to 
> differentiate clients?
>
>
> On 24.11.2015 12:22, Nikunj Badjatya wrote:
>
> Hello,
>
> Currently for our application, all django logs are generated and kept at 
> '/var/log/django.log'
> We want to have different log files for different clients. i.e. 
> /var/log/client-1/django.log
> /var/log/client-2/django.log
> /var/log/client-3/django.log
> 
> 
>
> The request object has information about the logged in user (and thus 
> client). These inturn are stored in a mysql database. 
>
> How can django log file path be modified dynamically such that when 
> client-1 is using the application, his logs go into 
> '/var/log/client-1/django.log' and so on for other clients ?
>
> Using Django 1.6.11 and Python 2.7.
> 'LOGGING' is defined in settings.py.
>
> Thanks.
>
> -- 
> 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...@googlegroups.com .
> To post to this group, send email to django...@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/c7c7d27a-2804-4993-8bb9-dd9c3fb7eeab%40googlegroups.com?utm_medium=email_source=footer>
> https://groups.google.com/d/msgid/django-users/c7c7d27a-2804-4993-8bb9-dd9c3fb7eeab%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/4e6070d9-b589-4001-b2c2-c9d3bbe8a4d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using request object in settings.py for custom logging

[Jani Tiainen]

Hi,

Problem is that you quite certainly have different users and several 
processess/threads which would lead logging configuration per request.


Is there a reason you don't use something like sites framework to 
differentiate clients?



On 24.11.2015 12:22, Nikunj Badjatya wrote:

Hello,

Currently for our application, all django logs are generated and kept 
at '/var/log/django.log'

We want to have different log files for different clients. i.e.
/var/log/client-1/django.log
/var/log/client-2/django.log
/var/log/client-3/django.log



The request object has information about the logged in user (and thus 
client). These inturn are stored in a mysql database.


How can django log file path be modified dynamically such that when 
client-1 is using the application, his logs go into 
'/var/log/client-1/django.log' and so on for other clients ?


Using Django 1.6.11 and Python 2.7.
'LOGGING' is defined in settings.py.

Thanks.

--
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 
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com 
<mailto: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/c7c7d27a-2804-4993-8bb9-dd9c3fb7eeab%40googlegroups.com 
<https://groups.google.com/d/msgid/django-users/c7c7d27a-2804-4993-8bb9-dd9c3fb7eeab%40googlegroups.com?utm_medium=email_source=footer>.

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/565448CB.9060203%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Using request object in settings.py for custom logging

[Nikunj Badjatya]

Hello,

Currently for our application, all django logs are generated and kept at 
'/var/log/django.log'
We want to have different log files for different clients. i.e. 
/var/log/client-1/django.log
/var/log/client-2/django.log
/var/log/client-3/django.log



The request object has information about the logged in user (and thus 
client). These inturn are stored in a mysql database. 

How can django log file path be modified dynamically such that when 
client-1 is using the application, his logs go into 
'/var/log/client-1/django.log' and so on for other clients ?

Using Django 1.6.11 and Python 2.7.
'LOGGING' is defined in settings.py.

Thanks.

-- 
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/c7c7d27a-2804-4993-8bb9-dd9c3fb7eeab%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 <mortas...@gmail.com>:

> 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
> <https://groups.google.com/d/msgid/django-users/033933b4-fb7b-46ca-bdf5-ada2011cb902%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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.

Access request object in a custom template tag

[Ponytech]

Hello,

I am currently writing a custom template tag and I need to access the 
request object within the tag code.
When using tag helpers (*simple_tag*, *inclusion_tag *and *assignment_tag*) 
you can register them with an additional takes_context=True parameter that 
makes the request object available.
But this does not work with the low level *tag* decorator:

@register.tag(takes_context=True)def mytag(parser, token):
   ...

raises the exception:  *tag() got an unexpected keyword argument 
'takes_context'*
*
*
2 questions :

- is there a reason why the tag decorator does accept the takes_context 
argument ?
- how can I access the template context with this decorator (and thus the 
request object) ?


Thanks a lot.

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how should I get the request object?

[Russell Keith-Magee]

On Tue, Nov 27, 2012 at 12:38 PM, Wade Williams
<wwilli...@local-motors.com>wrote:

> I share the disdain for global variables as well.
>
> I'm fairly new to Django, and what I'm not understanding is when the
> request object is available for inclusion. I have a custom session backend
> that I've built in order to support a legacy user model and session table
> -- when I tried to simply add the request parameter from this backend, I
> got number of parameter errors, so it seems that it isn't totally available
> all of the time.
>
> Im currently patching this with a similarly horrible settings.request var
> that simply contains the request, so an import of settings makes this work.
>
> But again, that's icky, and horrible, and no, so when exactly can you add
> the request parameter, and when can't you ?
>
>
> Thanks so much for the clarification. Lots of search attempts and still
> not understanding when it's automatically passed in as a parameter / how
> that even gets passed to the method. As far as I can tell, middleware and
> views both have access to the request, but is it simply the wrong thing to
> try and access the request in some other place ?
>
>
I'm afraid I don't even understand the question here. When is it legal to
access the request? Whenever it's been passed in as an argument to whatever
function is in use. When is it passed in as an argument? Whenever it's in
the method prototype.

You say you're putting data on the settings object in order to preserve the
request. Firstly, this scares the bejeezus out of me, above and beyond my
earlier comments about globals. Using thread locals is bad architecture,
but at least it will work. If you're just setting settings.request,
hilarity *will* ensue as soon as you have a real production scenario --
request objects will be shared between threads, meaning all sorts of
session leakage, security problems and more.

Lastly, you say you need the request object for your session backend. I'm
not entirely sure I see why you need the request object for this -- the API
for a session store is based on the idea that a session key can be used to
retrieve session data; it should be independent of a User model. However,
assuming you have a real reason for doing this, the way to get the request
object into the session store is to write a custom SessionMiddleware that
passes in the request object when the session object is instantiated. No
special magic required -- find the place where request is needed, add it to
the method prototype, and add it to the call when the method is used.

There's no "automatic" anything going on here. request is either an
argument on a method, or it isn't. Part of the contract for a view is that
the first argument is the request object. However, that's no different to
saying that the first argument to open() is a file name, or that the first
argument to __getitem__() is the index of the object you want to return. If
you need the request to be available somewhere, then you need to find the
call path from the middleware/view to whatever code needs the request
object.

Yours,
Russ Magee %-)

-- 
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: how should I get the request object?

[Wade Williams]

I share the disdain for global variables as well.

I'm fairly new to Django, and what I'm not understanding is when the 
request object is available for inclusion. I have a custom session backend 
that I've built in order to support a legacy user model and session table 
-- when I tried to simply add the request parameter from this backend, I 
got number of parameter errors, so it seems that it isn't totally available 
all of the time. 

Im currently patching this with a similarly horrible settings.request var 
that simply contains the request, so an import of settings makes this work.

But again, that's icky, and horrible, and no, so when exactly can you add 
the request parameter, and when can't you ? 


Thanks so much for the clarification. Lots of search attempts and still not 
understanding when it's automatically passed in as a parameter / how that 
even gets passed to the method. As far as I can tell, middleware and views 
both have access to the request, but is it simply the wrong thing to try 
and access the request in some other place ? 



On Monday, November 26, 2012 4:47:42 PM UTC-7, Russell Keith-Magee wrote:
>
>
> This is an often proposed solution to the problem, but one that I can't 
> recommend to anybody.
>
> The very name of your proposed middleware -- GlobalRequest -- should point 
> at why it's a bad idea. You've just defined a global variable, and you've 
> architected your entire system around the availability around that 
> global. All the usual problems that are associated with global variables 
> will apply to what you have done here.
>
> You say you've done this because it is "inconvenient" to make a request 
> object available deep within the call stack?   Frankly, I call BS. Making 
> sure the request (or data from the request) is available where it is needed 
> is just good planning. Yes, good planning requires more work -- but it's 
> also work that results in a stronger product at the end of the day, because 
> you aren't building your code on a foundation of global variables. 
>
> Adding a request argument to a few functions isn't *that* hard. Suggesting 
> that you should put everything in global variables because it's too hard to 
> pass around some arguments… I don't even know where to start.
>
> Yours,
> Russ Magee %-)
>
> On Tue, Nov 27, 2012 at 2:39 AM, Mike S <mse...@gmail.com >wrote:
>
>> Sometimes it is very inconvenient to make the `request` object available 
>> deep in the call stack, so I wrote a short middleware to work around this 
>> issue:
>>
>> http://djangosnippets.org/snippets/2853/
>>
>>
>> On Monday, November 26, 2012 5:16:01 AM UTC-5, Miaobing Jiang wrote:
>>>
>>> how should I get the request object when I need that object in some 
>>> places rather than in the view for each view has request as its first 
>>> parameter?
>>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/django-users/-/WiwLtFzrh1QJ.
>>
>> To post to this group, send email to django...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-users...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-users?hl=en.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/Pzw1YdS7NhcJ.
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: how should I get the request object?

[Russell Keith-Magee]

This is an often proposed solution to the problem, but one that I can't
recommend to anybody.

The very name of your proposed middleware -- GlobalRequest -- should point
at why it's a bad idea. You've just defined a global variable, and you've
architected your entire system around the availability around that
global. All the usual problems that are associated with global variables
will apply to what you have done here.

You say you've done this because it is "inconvenient" to make a request
object available deep within the call stack?   Frankly, I call BS. Making
sure the request (or data from the request) is available where it is needed
is just good planning. Yes, good planning requires more work -- but it's
also work that results in a stronger product at the end of the day, because
you aren't building your code on a foundation of global variables.

Adding a request argument to a few functions isn't *that* hard. Suggesting
that you should put everything in global variables because it's too hard to
pass around some arguments… I don't even know where to start.

Yours,
Russ Magee %-)

On Tue, Nov 27, 2012 at 2:39 AM, Mike S <mse...@gmail.com> wrote:

> Sometimes it is very inconvenient to make the `request` object available
> deep in the call stack, so I wrote a short middleware to work around this
> issue:
>
> http://djangosnippets.org/snippets/2853/
>
>
> On Monday, November 26, 2012 5:16:01 AM UTC-5, Miaobing Jiang wrote:
>>
>> how should I get the request object when I need that object in some
>> places rather than in the view for each view has request as its first
>> parameter?
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/WiwLtFzrh1QJ.
>
> 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.
>

-- 
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: how should I get the request object?

[Mike S]

Sometimes it is very inconvenient to make the `request` object available 
deep in the call stack, so I wrote a short middleware to work around this 
issue:

http://djangosnippets.org/snippets/2853/

On Monday, November 26, 2012 5:16:01 AM UTC-5, Miaobing Jiang wrote:
>
> how should I get the request object when I need that object in some places 
> rather than in the view for each view has request as its first parameter?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/WiwLtFzrh1QJ.
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: how should I get the request object?

[Daniel Roseman]

On Monday, 26 November 2012 10:16:01 UTC, Miaobing Jiang wrote:

> how should I get the request object when I need that object in some places 
> rather than in the view for each view has request as its first parameter?
>

Pass it from the view into whatever functions need it.
--
DR.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/bklR9Qpd2VoJ.
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.

how should I get the request object?

[Miaobing Jiang]

how should I get the request object when I need that object in some places 
rather than in the view for each view has request as its first parameter?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/KxbF80i-SawJ.
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.

request object in custom TEMPLATE_LOADER

[mmuk2]

Hi,

I'm sure this question has been asked before, but I thought I'd throw it 
out there as it's something I've come across in a project I'm working on at 
present.

What is the best way to include a request object in a custom 
template_loader?

The reason I need the request object available in my custom template loader 
is so that I can check the device that the request is coming on and load a 
different template for each device.

Any help would be greatly appreciated.

thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/XLOLy6KajkcJ.
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: Why can't forms access the request object?

[Tom Evans]

On Mon, Mar 12, 2012 at 12:34 PM, Matt Schinckel <m...@schinckel.net> wrote:
> You are mixing up views and forms. The OP was asking about forms, not views.
>
> Personally, I'm starting to hit more and more cases where I would like the
> form to be able to access the request (and associated data). For instance,
> being able to limit the queryset of choices for a related field, depending
> upon the logged in user.
>
> (I have an API framework that uses forms for de/serialisation, called
> django-repose, but it's not fully ready for human consumption. I'm still
> thinking about the best way to handle this particular issue, for instance).
>
> Matt.
>

If your form requires access to the request object, or to the
currently logged in user, it should simply take that object as an
additional required argument to the form constructor. There should be
no need for any magic here.

Cheers

Tom

-- 
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: Why can't forms access the request object?

[Matt Schinckel]

You are mixing up views and forms. The OP was asking about forms, not views.

Personally, I'm starting to hit more and more cases where I would like the 
form to be able to access the request (and associated data). For instance, 
being able to limit the queryset of choices for a related field, depending 
upon the logged in user.

(I have an API framework that uses forms for de/serialisation, called 
django-repose, but it's not fully ready for human consumption. I'm still 
thinking about the best way to handle this particular issue, for instance).

Matt.

On Monday, March 12, 2012 6:17:17 PM UTC+10:30, skhohlov wrote:
>
> Shacker,
>  Django migrates  from function based view to the class based. It will
> be nice to catch a good resource about class view usage because
> official documentation is very poor.
>
> 2012/3/12 shacker <shac...@birdhouse.org>:
> > Thanks for the explanations Masklinn and dstuffte - this makes a lot more
> > sense now. I guess I was thinking of this in more simplistic terms - I 
> was
> > assuming that a form is always invoked from a view, so naturally it would
> > inherit the request object. I'm having trouble thinking of  a use case 
> where
> > a  form would  not be part of any request/response cycle, but if that 
> were
> > true, then you're right - it would not be necessarily connected to 
> request.
> >
> >
> > Also, I see that part of the problem is that a view is a *function* and 
> its
> >  args  are passed context objects, while a form is a *class* and its 
>  args
> > are only what class it inherits from - so yeah, there's a semantics 
> problem
> > of how one would pass in request.
> >
> > And you're right, it's not a hard problem to solve - just that the 
> solution
> > is a bit more verbose than I'd like it to be.
> >
> > Thanks again,
> > ./s
> >>
> >>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msg/django-users/-/G0UkLvyadAgJ.
> >
> > 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/K1w7NHduiAgJ.
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: Why can't forms access the request object?

[Sergiy Khohlov]

Shacker,
 Django migrates  from function based view to the class based. It will
be nice to catch a good resource about class view usage because
official documentation is very poor.

2012/3/12 shacker <shac...@birdhouse.org>:
> Thanks for the explanations Masklinn and dstuffte - this makes a lot more
> sense now. I guess I was thinking of this in more simplistic terms - I was
> assuming that a form is always invoked from a view, so naturally it would
> inherit the request object. I'm having trouble thinking of  a use case where
> a  form would  not be part of any request/response cycle, but if that were
> true, then you're right - it would not be necessarily connected to request.
>
>
> Also, I see that part of the problem is that a view is a *function* and its
>  args  are passed context objects, while a form is a *class* and its  args
> are only what class it inherits from - so yeah, there's a semantics problem
> of how one would pass in request.
>
> And you're right, it's not a hard problem to solve - just that the solution
> is a bit more verbose than I'd like it to be.
>
> Thanks again,
> ./s
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/G0UkLvyadAgJ.
>
> 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.

-- 
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: Why can't forms access the request object?

[shacker]

Thanks for the explanations Masklinn and dstuffte - this makes a lot more 
sense now. I guess I was thinking of this in more simplistic terms - I was 
assuming that a form is always invoked from a view, so naturally it would 
inherit the request object. I'm having trouble thinking of  a use case 
where a  form would  not be part of any request/response cycle, but if that 
were true, then you're right - it would not be necessarily connected to 
request.  

Also, I see that part of the problem is that a view is a *function* and its 
 args  are passed context objects, while a form is a *class* and its  args 
are only what class it inherits from - so yeah, there's a semantics problem 
of how one would pass in request.

And you're right, it's not a hard problem to solve - just that the solution 
is a bit more verbose than I'd like it to be.  

Thanks again,
./s

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/G0UkLvyadAgJ.
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: Why can't forms access the request object?

[Donald Stufft]

On Sunday, March 11, 2012 at 12:43 PM, shacker wrote:
> On Sunday, March 11, 2012 6:24:30 AM UTC-7, skhohlov wrote:
> > Of course form  does not have access to the object. 
> 
> 
> skholov - Thanks, but you misunderstand my question. Again, I know that forms 
> don't have access to request, and again, I've got it working already (though 
> with a different approach - see my OP). My question was an attempt to 
> understand the plumbing or the python better. To reiterate, I'd like to know 
> WHY request isn't automatically available from forms, as it is from views. To 
> put the question another way, when we define a view function, we do something 
> like:
> 
> def edit(request,story_id):
>   ...
This is a function that get's passed request as it's first argument. Since view 
functions are _always_ run during the request response cycle of an HTTP 
request, request is always available to be passed into the view. 
> 
> But when we create a form, we can't just do:
> 
> class StoryForm(ModelForm, request):
>   ...
> 
> 

This is subclassing the form from request. the equivalent code would be to 
accept the request in the forms __init__, 
however this would need to be option to still allow using the forms outside of 
the request, response cycle. This parameter
is very easy to add on your own and including it by default needlessly ties the 
form processing library to django requests.
> 
> It seems like this is the kind of thing Django could take care of for us - we 
> shouldn't have to jump through hoops to get at request -  but there's 
> probably a good reason why it works this way. Does my question make more 
> sense now? 
> 
> Thanks,
> Scot
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-users/-/8DXqXSX-YhAJ.
> To post to this group, send email to django-users@googlegroups.com 
> (mailto:django-users@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com 
> (mailto:django-users+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.

-- 
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: Why can't forms access the request object?

[Masklinn]

On 2012-03-11, at 17:43 , shacker wrote:
> On Sunday, March 11, 2012 6:24:30 AM UTC-7, skhohlov wrote:
>> 
>> Of course form  does not have access to the object. 
> 
> 
> skholov - Thanks, but you misunderstand my question. Again, I know that 
> forms don't have access to request, and again, I've got it working already 
> (though with a different approach - see my OP). My question was an attempt 
> to understand the plumbing or the python better. To reiterate, I'd like to 
> know WHY request isn't automatically available from forms, as it is from 
> views.

1. Because there are no paths to do it automatically, this would require
passing the request object to all forms explicitly

2. Because, as Donald noted, forms don't *need* a request object and
indeed can be used completely independently from the request/response
cycle (or from a given request).

3. Plus what would be the semantics there, would the form prime itself
using request.POST? request.GET? A combination of both? Only under some
request methods?

Views exist to handle requests, that's all their job is, so them
receiving a request object makes perfect sense. Not so for forms.

> To put the question another way, when we define a view function, we 
> do something like:
> 
> def edit(request,story_id):
>  ...
> 
> But when we create a form, we can't just do:
> 
> class StoryForm(ModelForm, request):
>  …

For what it's worth, this code makes absolutely no sense, it tries to
create a class which inherits from a request object (which is not in
scope and is not a type)


-- 
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: Why can't forms access the request object?

[shacker]

On Sunday, March 11, 2012 6:24:30 AM UTC-7, skhohlov wrote:
>
> Of course form  does not have access to the object. 


skholov - Thanks, but you misunderstand my question. Again, I know that 
forms don't have access to request, and again, I've got it working already 
(though with a different approach - see my OP). My question was an attempt 
to understand the plumbing or the python better. To reiterate, I'd like to 
know WHY request isn't automatically available from forms, as it is from 
views. To put the question another way, when we define a view function, we 
do something like:

def edit(request,story_id):
  ...

But when we create a form, we can't just do:

class StoryForm(ModelForm, request):
  ...

It seems like this is the kind of thing Django could take care of for us - 
we shouldn't have to jump through hoops to get at request -  but there's 
probably a good reason why it works this way. Does my question make more 
sense now? 

Thanks,
Scot

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/8DXqXSX-YhAJ.
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: Why can't forms access the request object?

[Sergiy Khohlov]

Of course form  does not have access to the object. But  you can  pass
some value which is accessible  in view from view to form.
 Separating  task in 2 parts :

 1)  set initial  values in  view class

class myviewclass():
""" This is example only . full class realization is more complex """

form_class = myformclass
template_name = "mytemplate.html"

get_initial(self):
""" Passing initial values to the form"""

# At first initial data should be saved
super(myviewclass, self).get_initial()
 # adding  our value
self.initial= {"myuser": self.request.user}
return self.initial


Second part (form side)

myformclass():
"""  This is really simple example. Perfect form is more complex"""
def __init__(self, *args, **kwargs):
# get our values from view
myvalues = kwargs.pop('initial', None)
#print it to console (this is a dict by default)
print myvalues
# and executing default constructor after this
super(myformclass, self).__init__(*args, **kwargs)



 Thanks, Serge


2012/3/11 Donald Stufft <donald.stu...@gmail.com>:
> Forms aren't only usable from inside a view.
>
> On Sunday, March 11, 2012 at 4:32 AM, shacker wrote:
>
> I recently needed to access request.user in a form, and found that I
> couldn't. Found many articles describing ways to accomplish this, such as
> James Bennett's [1].
>
> I did get it working, but I'm curious *why* the request object
> isn't accessible from forms as it is from views. Why do we need to override
> __init__  to accomplish this? Seems like the kind of thing Django could
> "take care of" for us.
>
> [1] http://www.b-list.org/weblog/2008/nov/09/dynamic-forms/
>
> Thanks to anyone who can clarify.
>
> ./s
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/1z9ElVqpRucJ.
> 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.
>
>
> --
> 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.

-- 
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: Why can't forms access the request object?

[Donald Stufft]

Forms aren't only usable from inside a view. 


On Sunday, March 11, 2012 at 4:32 AM, shacker wrote:

> I recently needed to access request.user in a form, and found that I 
> couldn't. Found many articles describing ways to accomplish this, such as 
> James Bennett's [1].
> 
> I did get it working, but I'm curious *why* the request object isn't 
> accessible from forms as it is from views. Why do we need to override 
> __init__  to accomplish this? Seems like the kind of thing Django could "take 
> care of" for us.
> 
> [1] http://www.b-list.org/weblog/2008/nov/09/dynamic-forms/
> 
> Thanks to anyone who can clarify.
> 
> ./s
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-users/-/1z9ElVqpRucJ.
> To post to this group, send email to django-users@googlegroups.com 
> (mailto:django-users@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com 
> (mailto:django-users+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.

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

Why can't forms access the request object?

[shacker]

I recently needed to access request.user in a form, and found that I 
couldn't. Found many articles describing ways to accomplish this, such as 
James Bennett's [1].

I did get it working, but I'm curious *why* the request object 
isn't accessible from forms as it is from views. Why do we need to override 
__init__  to accomplish this? Seems like the kind of thing Django could 
"take care of" for us.

[1] http://www.b-list.org/weblog/2008/nov/09/dynamic-forms/

Thanks to anyone who can clarify.

./s



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/1z9ElVqpRucJ.
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: how to get request object out of views

[bruno desthuilliers]

On Aug 9, 12:13 pm, Kejun He  wrote:
> On Tue, Aug 9, 2011 at 5:54 PM, bruno desthuilliers <
>
>
> > DONT import settings that way. ALWAYS use "from django.conf import
> > settings"
>
> I test in my development server, and found that
>
> from django.conf import settings   is to all client
>
> but
>
> import settings is to a singal one

I don't understand what you mean here. But anyway: the only correct
way to import your project's settings module is to use the first form.
It #1 respects the --settings option of ./manage.py (or the
$DJANGO_SETTINGS_MODULE environment variable - cf deploying on
mod_wsgi), and #2 makes sure you have the default values for what you
didn't set in you settings file.

>
> > > then assign request.user to settings.CURRENT_USER
>
> > Question: what do you think will happen in a multithreaded
> > environment ?
>
>  I just test it on my development server, and it could work normally when
> there are several users.

I'm talking about multithreaded environment here.

>  And have not test it in a  multithreaded environment.

Please do.

-- 
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: how to get request object out of views

[Kejun He]

hi,
I will do as your method

thanks for your reply

regards,
kejun

On Tue, Aug 9, 2011 at 5:56 PM, Tom Evans  wrote:

> On Tue, Aug 9, 2011 at 10:22 AM, Kejun He  wrote:
> > hi,
> > Ok, It is a good method to get the current user. I am sorry for that.
> >
> > But i just do maintain a django project, and i do not want to change the
> > template structure.
> >
> > And now, I have found a new method to resolve the problem.
> >
> > through a variable CURRENT_USER defined in settings.py to save the
> current
> > user  in a view.
> > and get the current_user from settings.CURRENT_USER.
> >
> > thanks for your reply.
> >
> >
> > And i found a strange appearance.
> >
> > PART_ONE:
> > I defined a variable named CURRENT_USER
> >
> > and import the settings in a view like below:
> >
> > from gmadmin import settings  ## the gmadmin is the
> name
> > of the topo directory
> >
> > then assign request.user to settings.CURRENT_USER
> >
> > PART_TWO:
> > Get the settings.CURRENT_USER  in a .py file
> >
> > the code:
> > import settings
> > user = settings.CURRENT_USER
> >
> >
> > But it reported a problem: the settings.CURRENT_USER is None .
> > and the problem disappeared when i use "import settings" instead of "from
> > gmadmin import settings" on PART_ONE。
> >
> >
> > Could you talk about it?
> >
> > regards,
> > kejun
> >
>
> You should not do this.
>
>
> https://docs.djangoproject.com/en/1.3/topics/settings/#altering-settings-at-runtime
>
> If a function needs a user object, pass it a user object as an
> argument. Using globals is a clear sign that you haven't understood
> the problem. Don't do it. I gave you a precise way of achieving this
> without futzing around with anti-patterns.
>
> Cheers
>
> Tom
>
> --
> 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.
>
>

-- 
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: how to get request object out of views

[Kejun He]

On Tue, Aug 9, 2011 at 5:54 PM, bruno desthuilliers <
bruno.desthuilli...@gmail.com> wrote:

> On Aug 9, 11:22 am, Kejun He  wrote:
> > hi,
> > Ok, It is a good method to get the current user.
>
> It's actually THE good method.
>
> >
> > But i just do maintain a django project, and i do not want to change the
> > template structure.
> >
> > And now, I have found a new method to resolve the problem.
> >
> > through a variable CURRENT_USER defined in settings.py to save the
> current
> > user  in a view.
> > and get the current_user from settings.CURRENT_USER.
>
> How ? And does it really works ?-)
> (hint: whatever you might think, it's totally broken)
>
> > And i found a strange appearance.
> >
> > PART_ONE:
> > I defined a variable named CURRENT_USER
> >
> > and import the settings in a view like below:
> >
> > from gmadmin import settings  ## the gmadmin is the
> name
> > of the topo directory
>
> DONT import settings that way. ALWAYS use "from django.conf import
> settings"
>

I test in my development server, and found that

from django.conf import settings   is to all client

but

import settings is to a singal one

>
> >
> > then assign request.user to settings.CURRENT_USER
>
> Question: what do you think will happen in a multithreaded
> environment ?
>

 I just test it on my development server, and it could work normally when
there are several users.
 And have not test it in a  multithreaded environment.


> > PART_TWO:
> > Get the settings.CURRENT_USER  in a .py file
> >
> > the code:
> > import settings
> > user = settings.CURRENT_USER
> >
> > But it reported a problem: the settings.CURRENT_USER is None .
> > and the problem disappeared when i use "import settings" instead of "from
> > gmadmin import settings" on PART_ONE。
> >
> > Could you talk about it?
>
> It would be better if you learned enough about Django and Python to
> find out by yourself - and why this approach will never work.
>
> In the meantime, save yourself some pain and do things the right way
> (IOW: do has Tom said).
>

my method is not a normal way on django


thanks for your suggestion， I will spend enough time to learned django, i am
so new

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

-- 
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: how to get request object out of views

[Tom Evans]

On Tue, Aug 9, 2011 at 10:22 AM, Kejun He  wrote:
> hi,
> Ok, It is a good method to get the current user. I am sorry for that.
>
> But i just do maintain a django project, and i do not want to change the
> template structure.
>
> And now, I have found a new method to resolve the problem.
>
> through a variable CURRENT_USER defined in settings.py to save the current
> user  in a view.
> and get the current_user from settings.CURRENT_USER.
>
> thanks for your reply.
>
>
> And i found a strange appearance.
>
> PART_ONE:
> I defined a variable named CURRENT_USER
>
> and import the settings in a view like below:
>
> from gmadmin import settings  ## the gmadmin is the name
> of the topo directory
>
> then assign request.user to settings.CURRENT_USER
>
> PART_TWO:
> Get the settings.CURRENT_USER  in a .py file
>
> the code:
> import settings
> user = settings.CURRENT_USER
>
>
> But it reported a problem: the settings.CURRENT_USER is None .
> and the problem disappeared when i use "import settings" instead of "from
> gmadmin import settings" on PART_ONE。
>
>
> Could you talk about it?
>
> regards,
> kejun
>

You should not do this.

https://docs.djangoproject.com/en/1.3/topics/settings/#altering-settings-at-runtime

If a function needs a user object, pass it a user object as an
argument. Using globals is a clear sign that you haven't understood
the problem. Don't do it. I gave you a precise way of achieving this
without futzing around with anti-patterns.

Cheers

Tom

-- 
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: how to get request object out of views

[bruno desthuilliers]

On Aug 9, 11:22 am, Kejun He  wrote:
> hi,
> Ok, It is a good method to get the current user.

It's actually THE good method.

>
> But i just do maintain a django project, and i do not want to change the
> template structure.
>
> And now, I have found a new method to resolve the problem.
>
> through a variable CURRENT_USER defined in settings.py to save the current
> user  in a view.
> and get the current_user from settings.CURRENT_USER.

How ? And does it really works ?-)
(hint: whatever you might think, it's totally broken)

> And i found a strange appearance.
>
> PART_ONE:
> I defined a variable named CURRENT_USER
>
> and import the settings in a view like below:
>
> from gmadmin import settings      ## the gmadmin is the name
> of the topo directory

DONT import settings that way. ALWAYS use "from django.conf import
settings"

>
> then assign request.user to settings.CURRENT_USER

Question: what do you think will happen in a multithreaded
environment ?

> PART_TWO:
> Get the settings.CURRENT_USER  in a .py file
>
> the code:
> import settings
> user = settings.CURRENT_USER
>
> But it reported a problem: the settings.CURRENT_USER is None .
> and the problem disappeared when i use "import settings" instead of "from
> gmadmin import settings" on PART_ONE。
>
> Could you talk about it?

It would be better if you learned enough about Django and Python to
find out by yourself - and why this approach will never work.

In the meantime, save yourself some pain and do things the right way
(IOW: do has Tom said).

-- 
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: how to get request object out of views

[Kejun He]

hi,
Ok, It is a good method to get the current user. I am sorry for that.

But i just do maintain a django project, and i do not want to change the
template structure.

And now, I have found a new method to resolve the problem.

through a variable CURRENT_USER defined in settings.py to save the current
user  in a view.
and get the current_user from settings.CURRENT_USER.

thanks for your reply.


And i found a strange appearance.

PART_ONE:
I defined a variable named CURRENT_USER

and import the settings in a view like below:

from gmadmin import settings  ## the gmadmin is the name
of the topo directory

then assign request.user to settings.CURRENT_USER

PART_TWO:
Get the settings.CURRENT_USER  in a .py file

the code:
import settings
user = settings.CURRENT_USER


But it reported a problem: the settings.CURRENT_USER is None .
and the problem disappeared when i use "import settings" instead of "from
gmadmin import settings" on PART_ONE。


Could you talk about it?

regards,
kejun


On Tue, Aug 9, 2011 at 4:23 PM, Daniel Roseman wrote:

>
> On Tuesday, 9 August 2011 02:33:47 UTC+1, oops wrote:
>>
>> Hi,
>>
>> May be you miss understanted my meaning.
>>
>> I just want to get the current user object in a normal .py file out of
>> views.
>>
>> And this file just offer some data according to different user.
>>
>> Do you have any methods to get the goal?
>>
>> thank you
>>
>> regards,
>> kejun
>>
>
> No, Tom understood you fine, and his answer was quite clear. Get the user
> from the template context into your tag, and pass it from there into the
> list function.
> --
> DR.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/LwpPt4GXW8sJ.
>
> 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.
>

-- 
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: how to get request object out of views

[Daniel Roseman]

On Tuesday, 9 August 2011 02:33:47 UTC+1, oops wrote:
>
> Hi,
>
> May be you miss understanted my meaning.
>
> I just want to get the current user object in a normal .py file out of 
> views.
>
> And this file just offer some data according to different user.
>
> Do you have any methods to get the goal?
>
> thank you 
>
> regards,
> kejun  
>

No, Tom understood you fine, and his answer was quite clear. Get the user 
from the template context into your tag, and pass it from there into the 
list function.
--
DR. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/LwpPt4GXW8sJ.
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: how to get request object out of views

[Kejun He]

Hi,

May be you miss understanted my meaning.

I just want to get the current user object in a normal .py file out of
views.

And this file just offer some data according to different user.

Do you have any methods to get the goal?

thank you

regards,
kejun

On Mon, Aug 8, 2011 at 11:49 PM, Tom Evans <tevans...@googlemail.com> wrote:

> On Mon, Aug 8, 2011 at 4:19 PM, Kejun He <printer...@gmail.com> wrote:
> > hi,
> > My goal is to generate some data,
> > For example:
> > I defined a template tag, and it is used to generate a menutree, the item
> of
> > the menutree is a list.
> > The list  comes from another .py file.In this file,I want to get a
> current
> > user object(LIKE:request.user),
> >  so I need to get a request object outside the views.
> > or other method to get the current user object is fine.
> > thanks
> > regards,
> > kejun
>
> Put the current user into the template context, and pull the user out
> of the context supplied to your template tag.
>
> A common way of putting the current user into the template context is
> to use a RequestContext to render the template with, and ensure that
> 'django.contrib.auth.context_processors.auth' is in
> settings.TEMPLATE_CONTEXT_PROCESSORS (it is by default).
>
> Template tags are passed the context by default when render() is
> called on the Node returned by the template tag. If you are avoiding
> most of the messiness by using the @simple_tag decorator, you can pass
> @simple_tag(takes_context=True) to be passed the context. See [1].
>
> Cheers
>
> Tom
>
> [1]
> https://docs.djangoproject.com/en/1.3/howto/custom-template-tags/#shortcut-for-simple-tags
>
> --
> 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.
>
>

-- 
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: how to get request object out of views

[Tom Evans]

On Mon, Aug 8, 2011 at 4:19 PM, Kejun He <printer...@gmail.com> wrote:
> hi,
> My goal is to generate some data,
> For example:
> I defined a template tag, and it is used to generate a menutree, the item of
> the menutree is a list.
> The list  comes from another .py file.In this file,I want to get a current
> user object(LIKE:request.user),
>  so I need to get a request object outside the views.
> or other method to get the current user object is fine.
> thanks
> regards,
> kejun

Put the current user into the template context, and pull the user out
of the context supplied to your template tag.

A common way of putting the current user into the template context is
to use a RequestContext to render the template with, and ensure that
'django.contrib.auth.context_processors.auth' is in
settings.TEMPLATE_CONTEXT_PROCESSORS (it is by default).

Template tags are passed the context by default when render() is
called on the Node returned by the template tag. If you are avoiding
most of the messiness by using the @simple_tag decorator, you can pass
@simple_tag(takes_context=True) to be passed the context. See [1].

Cheers

Tom

[1] 
https://docs.djangoproject.com/en/1.3/howto/custom-template-tags/#shortcut-for-simple-tags

-- 
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: how to get request object out of views

[Kejun He]

hi,

My goal is to generate some data,

For example:

I defined a template tag, and it is used to generate a menutree, the item of
the menutree is a list.
The list  comes from another .py file.In this file,I want to get a current
user object(LIKE:request.user),
 so I need to get a request object outside the views.

or other method to get the current user object is fine.

thanks

regards,
kejun

-- 
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: how to get request object out of views

[Daniel Roseman]

On Monday, 8 August 2011 11:08:29 UTC+1, oops wrote:
>
> Hi,
>
> I try to get a request object out of views.py, and could not get the 
> reqeust object through "def demo(request)".
>
> Could you tell me how to get it??
>
> Or is there  other ways to get the same goal.
>
> Thanks very much
>
> regards,
> kejun  
>


If you need the request somewhere outside of a views, you need to pass it in 
from there.

Since you don't say what your goal is, we can't advise on other methods to 
reach it.
--
DR.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/QO0OxWxdH8sJ.
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.

how to get request object out of views

[Kejun He]

Hi,

I try to get a request object out of views.py, and could not get the reqeust
object through "def demo(request)".

Could you tell me how to get it??

Or is there  other ways to get the same goal.

Thanks very much

regards,
kejun

-- 
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: using the request object inside a form

[vanderkerkoff]

Thanks Daniel

I told you I was doing something stupid :-)

V

On Aug 2, 5:22 pm, Daniel Roseman  wrote:
> The problem isn't in the code you've posted, but in how you instantiate the 
> form in your view. You need to actually pass in 'request' as a keyword 
> argument.
> --
> 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.

using the request object inside a form

[Daniel Roseman]

The problem isn't in the code you've posted, but in how you instantiate the 
form in your view. You need to actually pass in 'request' as a keyword 
argument. 
-- 
DR. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/oKK3SC0IwHkJ.
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.

using the request object inside a form

[vanderkerkoff]

Hello there.

I need to use parts of the URL to calculate some thing inside my form.

Here's a stripped down version, I can't seem to get it to give me
anything other than none for self.request :-(

class EventBookForm(ModelForm):
title = CharField()
firstname = CharField()
surname = CharField()
address = CharField(widget=Textarea(attrs={'rows': 5, 'cols': 80}))
postcode = CharField()
telephone = CharField()
email = EmailField()
workshops = MultipleChoiceField()
requirements = CharField(widget=Textarea(attrs={'rows': 5, 'cols':
80}))

class Meta:
model = Event

def __init__(self, *args, **kwargs):
self.request = kwargs.pop('request', None)
print self.request
super(EventBookForm, self).__init__(*args, **kwargs)
workshop_choices = []
data = Workshop.objects.filter("some rules based on what I get 
back
from the request object, which is currently none")
for d in data:
workshop_choices.append((d.title,d.title))

self.fields['workshops']=MultipleChoiceField(widget=CheckboxSelectMultiple,
choices=workshop_choices, required=False)

I'm pretty certain I'm doing something unbelievably stupid but I am
trying, honestly!

Anyone got any ideas?

-- 
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: Pass 'request' object to Form

[Tom Evans]

On Thu, Feb 10, 2011 at 7:52 AM, NavaTux <navaneetha...@gmail.com> wrote:
> Hi all,
>            i have been using modelform in my site,Now i want to do filter
> the
> objects(only today generated) in the particular model(TAG) ,for that
> constraint
> TAGS has to be generated today only, because while retrieving all objects in
> a
> particular many_to_many(TAG) field it is quite slow to process
>             As well as in my application flow i need a request object to do
> this,
> from that request i have to filter the site(HTTP_HOST),(ofcourse using two
> sites)
> then for that site only the particular tags has be loaded
>               Here my doubt is
>                      I need to pass the 'request' object to my form(model
> form)
> Is it possible? because, the 'request' object is passing to view from the
> form
> by
> template CORRECT?
>              or Is it possibe to pass a object from 'view' to 'form'
> reversely??
>

You construct your form in the view, so you can pass anything you like
to the form when you call its constructor. Simply override the form's
constructor, and make sure not to pass your supplemental arguments
onto the base form constructor when you call it.

Eg:

class MyModelForm(forms.ModelForm):
def __init__(self, *args, **kwargs):
self.request = kwargs.pop('request')
super(MyModelForm, self).__init__(*args, **kwargs)

Cheers

Tom

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

Pass 'request' object to Form

[NavaTux]

Hi all,

   i have been using modelform in my site,Now i want to do filter 
the 
objects(only today generated) in the particular model(TAG) ,for that 
constraint 
TAGS has to be generated today only, because while retrieving all objects in 
a 
particular many_to_many(TAG) field it is quite slow to process

As well as in my application flow i need a request object to do 
this, 
from that request i have to filter the site(HTTP_HOST),(ofcourse using two 
sites) 
then for that site only the particular tags has be loaded 

  Here my doubt is 

 I need to pass the 'request' object to my form(model 
form) 
Is it possible? because, the 'request' object is passing to view from the 
form  
by 
template CORRECT?

 or Is it possibe to pass a object from 'view' to 'form' 
reversely??

-- 
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: Get request object in class based generic view and form

[roman]

Hello Simon,

> But I can't figure out how I can retrieve the request object in the class
> based generic view.

As far as I understand just get it from self.request.

> I want to re-verify the user once again to
> make sure his authenticated.
>

I always do it the way it's recommended in the docs, by decorating the
the dispatch() method:
http://docs.djangoproject.com/en/dev/topics/class-based-views/#decorating-class-based-views

Isn't that sufficient?

Regards Roman

-- 
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: Using custom / Extending default Request Object

[Tereska]

Thanks that's gr8!

On 2 Lut, 21:52, Daniel Roseman <dan...@roseman.org.uk> wrote:
> On Wednesday, February 2, 2011 8:38:58 PM UTC, Tereska wrote:
>
> > My RequestObject must contain information about user device (mobile,
> > tablets etc) with device capatibilites (resolution, video codecs
> > etc) .
> > It's a data collection not simple string. Then I want use it in views
> > and templates.
>
> So, simply attach your information as an attribute of the standard request
> object. No need to replace it. You probably want to do this in a middleware.
>
>     class DeviceInfoMiddleware(object):
>         def process_request(self, request):
>             request.device_info = {'resolution': '800x600', 'codecs':
> ['H264', 'WebM']}
>
> --
> 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: Using custom / Extending default Request Object

[Daniel Roseman]

On Wednesday, February 2, 2011 8:38:58 PM UTC, Tereska wrote:
>
> My RequestObject must contain information about user device (mobile, 
> tablets etc) with device capatibilites (resolution, video codecs 
> etc) . 
> It's a data collection not simple string. Then I want use it in views 
> and templates. 
>

So, simply attach your information as an attribute of the standard request 
object. No need to replace it. You probably want to do this in a middleware.

class DeviceInfoMiddleware(object):
def process_request(self, request):
request.device_info = {'resolution': '800x600', 'codecs': 
['H264', 'WebM']}

--
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: Using custom / Extending default Request Object

[Tereska]

My RequestObject must contain information about user device (mobile,
tablets etc) with device capatibilites (resolution, video codecs
etc) .
It's a data collection not simple string. Then I want use it in views
and templates.



On Feb 2, 9:27 pm, Daniel Roseman  wrote:
> On Wednesday, February 2, 2011 8:12:30 PM UTC, Tereska wrote:
>
> > I have to extend HttpRequest class and be able to use it in views
> > (request argument in each view must be instance of MyHttpRequest
> > class)
>
> > How to do that? (without extending BaseHandler)
>
> Why do you need to do this? What is your actual problem? The likelihood is
> that this is not the way to solve it.
> --
> 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: Using custom / Extending default Request Object

[Daniel Roseman]

On Wednesday, February 2, 2011 8:12:30 PM UTC, Tereska wrote:
>
> I have to extend HttpRequest class and be able to use it in views 
> (request argument in each view must be instance of MyHttpRequest 
> class) 
>
> How to do that? (without extending BaseHandler) 
>
>
Why do you need to do this? What is your actual problem? The likelihood is 
that this is not the way to solve it.
--
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.

Using custom / Extending default Request Object

[Tereska]

I have to extend HttpRequest class and be able to use it in views
(request argument in each view must be instance of MyHttpRequest
class)

How to do that? (without extending BaseHandler)

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

Get request object in class based generic view and form

[Simon W]

Hi,
I'm trying to put up a modelform for users to edit their 'projects'.

But I can't figure out how I can retrieve the request object in the class
based generic view. I need it to verify the user.

Also, when the form is submitted, I want to re-verify the user once again to
make sure his authenticated.

Anyone have a clue?

-- 
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: Request Object Data

[Jonas H.]

On 12/17/2010 10:18 PM, hank23 wrote:

Is data entered on an input screen automatically added to the request
when the screen is submitted? If so are there any special parameters
or settings in the screen controls which have to be set/coded to get
the entered data saved into the request and under what keys is the
data saved? Once in the request then how can I retrieve the data back
out of the request so that I access it and do something with it? I
have seen an example where some data is extracted back out of the
request using "request.POST['choice']". Can this code be used to
retrieve any data which is saved in the request? Thanks for the
help.



http://docs.djangoproject.com/en/dev/intro/tutorial04/

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-us...@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.

Request Object Data

[hank23]

Is data entered on an input screen automatically added to the request
when the screen is submitted? If so are there any special parameters
or settings in the screen controls which have to be set/coded to get
the entered data saved into the request and under what keys is the
data saved? Once in the request then how can I retrieve the data back
out of the request so that I access it and do something with it? I
have seen an example where some data is extracted back out of the
request using "request.POST['choice']". Can this code be used to
retrieve any data which is saved in the request? Thanks for the
help.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Need access to http basic authentication from request object inside view

[mortenlp]

Dear reader

I have been fighting this really simple problem for 12 straight hours
now.
I just really can't seem to gain access to the simple http
authorization string from my view-functions.

e.g: "Basic bWF4bTpwYXNzd29yZA=="

Here is my simple test function inside my views.py:

def authenticate(request):
if 'HTTP_AUTHORIZATION' in request.META:
return HttpResponse(request.META['HTTP_AUTHORIZATION'])
elif 'AUTHORIZATION' in request.META:
return HttpResponse(request.META['AUTHORIZATION'])
elif 'REMOTE_USER' in request.META:
return HttpResponse(request.META['REMOTE_USER'])
else:
return HttpResponse(request) #Output is appended below

All of these keys do not exist... and the complete request object does
not contain the string either.

Many experience this problem using apache+mod_wsgi because
"WSGIPassAuthorization on" has to be set.
However i am experiencing the problem both with the built-in-django-
deleopment-server and apache+mod_wsgi+"WSGIPassAuthorization on".

Client: Safari and CocoaRestClient - so i know the authentication get
sent

I would greatly appreciate any help in making an simple django example
app, that prints out the basic_http_auth_string.

Best wished
Morten Pedersen




The full request object print out like so:
,
POST:,
COOKIES:{'sessionid': '26efb99003df54f49b468faac87cf523'},
META:{'CONTENT_TYPE': 'text/plain',
 'DOCUMENT_ROOT': '/var/www',
 'GATEWAY_INTERFACE': 'CGI/1.1',
 'HTTP_ACCEPT': '*/*',
 'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
 'HTTP_ACCEPT_LANGUAGE': 'en-us',
 'HTTP_CONNECTION': 'keep-alive',
 'HTTP_COOKIE': 'sessionid=26efb99003df54f49b468faac87cf523',
 'HTTP_HOST': '172.16.116.130',
 'HTTP_USER_AGENT': 'CocoaRestClient/1 CFNetwork/454.9.8 Darwin/10.4.0
(i386) (MacBookPro5%2C5)',
 'PATH_INFO': u'/auth/authenticate/',
 'PATH_TRANSLATED': '/usr/local/rhk/var/rhkest/apache/django.wsgi/auth/
authenticate/',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '172.16.116.1',
 'REMOTE_PORT': '55399',
 'REQUEST_METHOD': 'GET',
 'REQUEST_URI': '/auth/authenticate/',
 'SCRIPT_FILENAME': '/usr/local/rhk/var/rhkest/apache/django.wsgi',
 'SCRIPT_NAME': u'',
 'SERVER_ADDR': '172.16.116.130',
 'SERVER_ADMIN': '(REMOVED)',
 'SERVER_NAME': '172.16.116.130',
 'SERVER_PORT': '80',
 'SERVER_PROTOCOL': 'HTTP/1.1',
 'SERVER_SIGNATURE': 'Apache/2.2.16 (Debian) Server at
172.16.116.130 Port 80\n',
 'SERVER_SOFTWARE': 'Apache/2.2.16 (Debian)',
 'mod_wsgi.application_group': '(REMOVED)|',
 'mod_wsgi.callable_object': 'application',
 'mod_wsgi.handler_script': '',
 'mod_wsgi.input_chunked': '0',
 'mod_wsgi.listener_host': '',
 'mod_wsgi.listener_port': '80',
 'mod_wsgi.process_group': '(REMOVED)',
 'mod_wsgi.request_handler': 'wsgi-script',
 'mod_wsgi.script_reloading': '1',
 'mod_wsgi.version': (3, 3),
 'wsgi.errors': ,
 'wsgi.file_wrapper': ,
 'wsgi.input': ,
 'wsgi.multiprocess': True,
 'wsgi.multithread': False,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 1)}>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Request object problem

[girish shabadimath]

ya correct, now i got complete picture of client.get() and RequestFactory,


On Wed, Sep 22, 2010 at 5:28 PM, bruno desthuilliers <
bruno.desthuilli...@gmail.com> wrote:

> On 22 sep, 13:17, girish shabadimath  wrote:
> > Thanks for the reply, actually the response object got using
> RequestFactory
> > is different from the one returned by client.get() function,,
>
> The reponse object you get using RequestFactory is the one returned by
> your view.
>
> > i think response object returned by client.get() supports
> response.template
> > and response.context['data'],,,
>
> The test.Client uses quite a few Django hooks (middlewares, signals
> etc) to takes care of all this:
>
> http://code.djangoproject.com/browser/django/trunk/django/test/client.py
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@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.
>
>


-- 
Girish M S

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Request object problem

[bruno desthuilliers]

On 22 sep, 13:17, girish shabadimath  wrote:
> Thanks for the reply, actually the response object got using RequestFactory
> is different from the one returned by client.get() function,,

The reponse object you get using RequestFactory is the one returned by
your view.

> i think response object returned by client.get() supports response.template
> and response.context['data'],,,

The test.Client uses quite a few Django hooks (middlewares, signals
etc) to takes care of all this:

http://code.djangoproject.com/browser/django/trunk/django/test/client.py

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Request object problem

[girish shabadimath]

Thanks for the reply, actually the response object got using RequestFactory
is different from the one returned by client.get() function,,

i think response object returned by client.get() supports response.template
and response.context['data'],,,

ref:( http://djangosnippets.org/snippets/963/ )






On Wed, Sep 22, 2010 at 4:24 PM, bruno desthuilliers <
bruno.desthuilli...@gmail.com> wrote:

> On 22 sep, 11:31, girish shabadimath <girishmss.1...@gmail.com> wrote:
> > hi all,
> >
> > i used django snippethttp://djangosnippets.org/snippets/963/
> >
> > and successfully created request object
> >
> > i checked the response.status_code its giving 200
> >
> > i checked response.content it matches with the browser source code
> >
> > when i issue *response.template* it gives error
> >  and* response.context* also not giving output,,
> >
> > i used template and context data in view function,,
> >
> > why its showing nothing..?
>
> because, while the template and context are used to build the response
> object, they are not part of it.  render_to_response(templatename,
> context, ...) is just a convenient shortcut that loads the template,
> render it with the context, and build an HttpResponse using the
> generated content.
>
> FWIW, Django is not only mostly well documented but also OSS, so you
> can read the code to see what's going on:
>
>
> http://code.djangoproject.com/browser/django/trunk/django/shortcuts/__init__.py
>
> http://code.djangoproject.com/browser/django/trunk/django/http/__init__.py#L302
>
> As you can see, the HttpResponse object is built from some content -
> how this content is generated is totally orthogonal.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>


-- 
Girish M S

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Request object problem

[bruno desthuilliers]

On 22 sep, 11:31, girish shabadimath <girishmss.1...@gmail.com> wrote:
> hi all,
>
> i used django snippethttp://djangosnippets.org/snippets/963/
>
> and successfully created request object
>
> i checked the response.status_code its giving 200
>
> i checked response.content it matches with the browser source code
>
> when i issue *response.template* it gives error
>  and* response.context* also not giving output,,
>
> i used template and context data in view function,,
>
> why its showing nothing..?

because, while the template and context are used to build the response
object, they are not part of it.  render_to_response(templatename,
context, ...) is just a convenient shortcut that loads the template,
render it with the context, and build an HttpResponse using the
generated content.

FWIW, Django is not only mostly well documented but also OSS, so you
can read the code to see what's going on:

http://code.djangoproject.com/browser/django/trunk/django/shortcuts/__init__.py
http://code.djangoproject.com/browser/django/trunk/django/http/__init__.py#L302

As you can see, the HttpResponse object is built from some content -
how this content is generated is totally orthogonal.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Request object problem

[girish shabadimath]

hi all,

i used django snippet http://djangosnippets.org/snippets/963/

and successfully created request object

i checked the response.status_code its giving 200

i checked response.content it matches with the browser source code

when i issue *response.template* it gives error
 and* response.context* also not giving output,,

i used template and context data in view function,,

why its showing nothing..?


shell cmds:

>>>rf = RequestFactory()
>>>get_req = rf.request('/details')

>>> response = detail(get_req, 27000)

>>> response.status_code

200
>>> response.content

'\n\ndetails\n

.\n\n\n'

>>> response.template

Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'HttpResponse' object has no attribute 'template'

>>> response.context['data']
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'HttpResponse' object has no attribute 'context'

-- 
Girish M S

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: request object in generic view?

[Łukasz Rekucki]

On 9 September 2010 05:46, akcom <cppco...@gmail.com> wrote:
> Is there anyway to access the request object from a generic view?
> Specifically, I'd like to access the request.user object.  I tried
> doing it as follows:
> (r'^$', 'django.views.generic.simple.direct_to_template', {'template':
> 'index.html', 'extra_context' : {'request' : request}}
> hoping that the dictionary element would be evaluated within the
> context of the view where request would be valid.
That would surely be too much magic.

>Alas I was mistaken.
>
> Any help would be much appreciated!
>

Generic views use RequestContext[1] as the context instance, so all
your context processors are executed. Just add
"django.core.context_processors.request"[2] to your
TEMPLATE_CONTEXT_PROCESSORS list and you'll have the "request" object
available in all your templates


[1]: 
http://docs.djangoproject.com/en/dev/ref/templates/api/#subclassing-context-requestcontext
[2]: 
http://docs.djangoproject.com/en/dev/ref/templates/api/#django-core-context-processors-request


-- 
Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

request object in generic view?

[akcom]

Is there anyway to access the request object from a generic view?
Specifically, I'd like to access the request.user object.  I tried
doing it as follows:
(r'^$', 'django.views.generic.simple.direct_to_template', {'template':
'index.html', 'extra_context' : {'request' : request}}
hoping that the dictionary element would be evaluated within the
context of the view where request would be valid.  Alas I was
mistaken.

Any help would be much appreciated!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Alternative to passing request object to every object/function?

[Scott Gould]

Have a read through this article, Dan:

http://www.b-list.org/weblog/2008/nov/09/dynamic-forms/

On Sep 2, 11:19 am, Dan Klaffenbach <danielklaffenb...@gmail.com>
wrote:
> On 2 Sep., 16:48, Daniel Roseman <dan...@roseman.org.uk> wrote:> It's not 
> clear exactly what you want. Using RequestContext and the
> > request context processor will ensure that the request is present in
> > all your templates. Is that enough?
>
> No. I'll give an example:
>
> I use a custom Acl class for checking the user's permissions (main
> idea: RBAC-like, with role and permission inheritance). Let's say I
> have a form model:
>
> I need the request.user e.g in my application's form models, because I
> need to create an Acl instance in the model in order to check if the
> user can edit fields or not. There are three cases:
> * user can edit form field
> * user can view value (form widget attribute = readonly)
> * user is not allowed to view field at all (do not add element to the
> form at all)
>
> Isn't there any other way to get at least the currently logged in user
> ('REMOTE_USER') in models? Passing the request parameter to models
> doesn't seem like good style to me, it bloats the code and makes it
> harder to read. I do not need the request object in my templates (I
> know this is possible), just in e.g. form models.
>
> Regards,
> Dan

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Alternative to passing request object to every object/function?

[Dan Klaffenbach]

On 2 Sep., 16:48, Daniel Roseman <dan...@roseman.org.uk> wrote:
> It's not clear exactly what you want. Using RequestContext and the
> request context processor will ensure that the request is present in
> all your templates. Is that enough?
No. I'll give an example:

I use a custom Acl class for checking the user's permissions (main
idea: RBAC-like, with role and permission inheritance). Let's say I
have a form model:

I need the request.user e.g in my application's form models, because I
need to create an Acl instance in the model in order to check if the
user can edit fields or not. There are three cases:
* user can edit form field
* user can view value (form widget attribute = readonly)
* user is not allowed to view field at all (do not add element to the
form at all)


Isn't there any other way to get at least the currently logged in user
('REMOTE_USER') in models? Passing the request parameter to models
doesn't seem like good style to me, it bloats the code and makes it
harder to read. I do not need the request object in my templates (I
know this is possible), just in e.g. form models.


Regards,
Dan

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Alternative to passing request object to every object/function?

[Daniel Roseman]

On Sep 2, 3:30 pm, Daniel Klaffenbach <danielklaffenb...@gmail.com>
wrote:
> Hi,
>
> I am developing a Django app which relies on information from the
> request object a lot, especially request.user. I need this object (or
> let's say at least 'REMOTE_USER') in many models and I was wondering
> if there is another way to get the request object?
>
> In PHP there is something like $_SERVER which is a global variable
> containing for example the REMOTE_USER. I'm afraid I haven't found the
> Python/Django equivalent yet, but since it is a bit stupid to always
> pass the request object as a parameter to objects and functions I am
> sure there is another (better) approach.
>
> Could someone point out what I should do in this case?
>
> Regards,
> Dan Klaffenbach

It's not clear exactly what you want. Using RequestContext and the
request context processor will ensure that the request is present in
all your templates. Is that enough?

You say though that you need it 'in many models' - do you mean model
methods? Can you give an example, perhaps there is a better way of
achieving what you want to do.
--
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-us...@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: Alternative to passing request object to every object/function?

[Tom Evans]

On Thu, Sep 2, 2010 at 3:30 PM, Daniel Klaffenbach
<danielklaffenb...@gmail.com> wrote:
> Hi,
>
> I am developing a Django app which relies on information from the
> request object a lot, especially request.user. I need this object (or
> let's say at least 'REMOTE_USER') in many models and I was wondering
> if there is another way to get the request object?
>
> In PHP there is something like $_SERVER which is a global variable
> containing for example the REMOTE_USER. I'm afraid I haven't found the
> Python/Django equivalent yet, but since it is a bit stupid to always
> pass the request object as a parameter to objects and functions I am
> sure there is another (better) approach.
>
> Could someone point out what I should do in this case?
>
>
> Regards,
> Dan Klaffenbach
>

Take the pain - part of django's design is that it isn't PHP, and
globals aren't exactly a good programming paradigm.

I would either pass the request object, or (better) actually pass the
objects/data that the function actually needs - eg request.user,
request.POST. This will be more verbose, but you (and future people
reading the code) will have a clearer understanding of what inputs the
function takes, and the function is not so readily tied to a
request/response cycle and so can be used outside of that context as
well.

Personally, I try to avoid passing the request to any function that is
not a view/middleware/etc, as it makes it harder to use that function
without a request.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Alternative to passing request object to every object/function?

[Daniel Klaffenbach]

Hi,

I am developing a Django app which relies on information from the
request object a lot, especially request.user. I need this object (or
let's say at least 'REMOTE_USER') in many models and I was wondering
if there is another way to get the request object?

In PHP there is something like $_SERVER which is a global variable
containing for example the REMOTE_USER. I'm afraid I haven't found the
Python/Django equivalent yet, but since it is a bit stupid to always
pass the request object as a parameter to objects and functions I am
sure there is another (better) approach.

Could someone point out what I should do in this case?


Regards,
Dan Klaffenbach

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Get request path without having a request object

[David De La Harpe Golden]

On 27/08/10 14:22, Sells, Fred wrote:

> I'm not sure of the thread safety of Django and wonder if I could store
> this object as a local variable of some module like

No, that is not likely to work except in a single-threaded* context, and
even then it's a bit fraught (just being single-threaded still doesn't
mean each request is handled by a _new_ process, if you're not careful
you could leave things set to values from old requests).

There is a recipe out there for using a django middleware that uses
thread-local variables to stash info from the django request [1], but
that also tends to be frowned upon by django people for a variety of
reasons [2].

Python, while obviously somewhat lisp-oid, also doesn't have lisp-like
dynamics that might be idiomatic in lisp land.

Sooo just give up and explicitly pass the datum you want down
through the call chain. That can be a pain, but at least python has the
*args/**kwargs mechanism that can make it fairly easy for one callable
to just pass on through unused kwargs to another (a pattern used quite a
bit in django itself).

(* aside: single-threaded multiple-process serving is often a viable
option for serving stuff, at least on linux, where processes are very
cheap, and does avoid threading issues nicely (remember ordinary python
2.x can be kinda sucky threading-wise anyway [3]). Ex-windows people on
linux/unix often jump to threading very prematurely, mistakenly
generalising from windows [4])


[1] http://djangosnippets.org/snippets/1605/
[2] http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser
[3] http://en.wikipedia.org/wiki/Global_Interpreter_Lock
[4]
http://stackoverflow.com/questions/47845/why-is-creating-a-new-process-more-expensive-on-windows-than-linux

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Get request path without having a request object

[Sells, Fred]

I've looked at http://www.djangobook.com/en/beta/chapter12/ and the
section on Using sessions outside of views which shows:

>>> from django.contrib.sessions.models import Session
>>> s =
Session.objects.get_object(pk='2b1189a188b44ad18c35e113ac6ceead')

But where does that pk come from?

I'm down deep in my module hierarchy and find I need a custom user
object that I stored in my session.  I'm not using Django Authentication
because I'm running behind a legacy system that already does all that
and I had to be compatible.

I'm not sure of the thread safety of Django and wonder if I could store
this object as a local variable of some module like

>From mysite.myapp import myPersistantStorage

myPersistantStorage.myUserObject = request.session['user']

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Get request path without having a request object

[cootetom]

I have finished and made this app available via it's own web site.
Take a look http://poedit.tomcoote.co.uk/




On Aug 1, 1:18 pm, cootetom <coote...@gmail.com> wrote:
> I have found some code that can get the request object.
>
> f = sys._getframe()
> while f:
>     request = f.f_locals.get('request')
>     if isinstance(request, HttpRequest):
>         path = request.path
>         break
>     f = f.f_back
>
> James: I understand completely what you are saying and have thought
> long and hard about how I can achieve what I'm doing without needing
> the above code. I am creating an app that will provide a UI to admins
> to translate the text on each web page. The app needs to keep a track
> of which text from the current active language locale files has been
> used in the rendering of the current page they're on. At the same time
> I didn't want to have to change the way in which developers mark text
> for translation. This meant that I needed to override the gettext and
> template translation tags with custom ones which first remembered what
> message ID's were being used and second just called the default Django
> versions of these methods. However neither gettext or the template
> translation tags need to be aware of the request but to remember which
> message ID's are in use for a page I needed to know about the request.
> My options were either change my overriding methods to also accept a
> request object or find the object via another means. The latter seemed
> easier on future development.
>
> My app is almost finished. I need to do a load of testing on it. I'm
> then going to place it into an existing site that uses locale files
> for it's text. After that, I plan to release it for download so that
> others can use it. It turns out really useful to have a UI that will
> manage locale text. I have looked at another one called rosetta but it
> was implemented into the admin system and so didn't have a way of
> showing which text was used on specific pages which I think is really
> useful, especially if clients want to get involved with text
> translation.
>
> On Aug 1, 4:23 am, James Bennett <ubernost...@gmail.com> wrote:
>
>
>
> > On Sat, Jul 31, 2010 at 12:37 PM, cootetom <coote...@gmail.com> wrote:
> > > Thanks Carlos but I'm trying to achieve getting the path without
> > > having to pass the request object.
>
> > In a word: don't.
>
> > Instead, design your system to pass the information you need where and
> > when you need it. This doesn't mean everything always has to sling
> > around a request object, just that you need to think carefully about
> > separation of concerns and which code needs to get at the request.
>
> > Do this, and in 6-12 months when you have to start making changes to
> > update your application, you'll be incredibly thankful that you did it
> > right the first time around.
>
> > --
> > "Bureaucrat Conrad, you are technically correct -- the best kind of 
> > correct."

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Get request path without having a request object

[cootetom]

I have found some code that can get the request object.

f = sys._getframe()
while f:
request = f.f_locals.get('request')
if isinstance(request, HttpRequest):
path = request.path
break
f = f.f_back


James: I understand completely what you are saying and have thought
long and hard about how I can achieve what I'm doing without needing
the above code. I am creating an app that will provide a UI to admins
to translate the text on each web page. The app needs to keep a track
of which text from the current active language locale files has been
used in the rendering of the current page they're on. At the same time
I didn't want to have to change the way in which developers mark text
for translation. This meant that I needed to override the gettext and
template translation tags with custom ones which first remembered what
message ID's were being used and second just called the default Django
versions of these methods. However neither gettext or the template
translation tags need to be aware of the request but to remember which
message ID's are in use for a page I needed to know about the request.
My options were either change my overriding methods to also accept a
request object or find the object via another means. The latter seemed
easier on future development.

My app is almost finished. I need to do a load of testing on it. I'm
then going to place it into an existing site that uses locale files
for it's text. After that, I plan to release it for download so that
others can use it. It turns out really useful to have a UI that will
manage locale text. I have looked at another one called rosetta but it
was implemented into the admin system and so didn't have a way of
showing which text was used on specific pages which I think is really
useful, especially if clients want to get involved with text
translation.




On Aug 1, 4:23 am, James Bennett <ubernost...@gmail.com> wrote:
> On Sat, Jul 31, 2010 at 12:37 PM, cootetom <coote...@gmail.com> wrote:
> > Thanks Carlos but I'm trying to achieve getting the path without
> > having to pass the request object.
>
> In a word: don't.
>
> Instead, design your system to pass the information you need where and
> when you need it. This doesn't mean everything always has to sling
> around a request object, just that you need to think carefully about
> separation of concerns and which code needs to get at the request.
>
> Do this, and in 6-12 months when you have to start making changes to
> update your application, you'll be incredibly thankful that you did it
> right the first time around.
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Get request path without having a request object

[James Bennett]

On Sat, Jul 31, 2010 at 12:37 PM, cootetom <coote...@gmail.com> wrote:
> Thanks Carlos but I'm trying to achieve getting the path without
> having to pass the request object.

In a word: don't.

Instead, design your system to pass the information you need where and
when you need it. This doesn't mean everything always has to sling
around a request object, just that you need to think carefully about
separation of concerns and which code needs to get at the request.

Do this, and in 6-12 months when you have to start making changes to
update your application, you'll be incredibly thankful that you did it
right the first time around.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Get request path without having a request object

[cootetom]

Thanks Carlos but I'm trying to achieve getting the path without
having to pass the request object.

On Jul 31, 7:11 pm, Carlos Daniel Ruvalcaba Valenzuela
<clsdan...@gmail.com> wrote:
> Just add django.core.context_processors.request to your
> TEMPLATE_CONTEXT_PROCESSORS, this way you can access the current
> request object in your template, you will have to use however
> RequestContext class with render_to_response,
>
> From docs:
>
> django.core.context_processors.request
>
> If TEMPLATE_CONTEXT_PROCESSORS contains this processor, every
> RequestContext will contain a variable request, which is the current
> HttpRequest. Note that this processor is not enabled by default;
> you'll have to activate it.
>
> Regards,
> Carlos Daniel Ruvalcaba Valenzuela

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Get request path without having a request object

[Carlos Daniel Ruvalcaba Valenzuela]

Just add django.core.context_processors.request to your
TEMPLATE_CONTEXT_PROCESSORS, this way you can access the current
request object in your template, you will have to use however
RequestContext class with render_to_response,

>From docs:

django.core.context_processors.request

If TEMPLATE_CONTEXT_PROCESSORS contains this processor, every
RequestContext will contain a variable request, which is the current
HttpRequest. Note that this processor is not enabled by default;
you'll have to activate it.

Regards,
Carlos Daniel Ruvalcaba Valenzuela

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Get request path without having a request object

[cootetom]

I think perhaps I'll also put this problem another way. I need to
cache data against the current web request without having the Django
built request object.



On Jul 31, 4:56 pm, cootetom <coote...@gmail.com> wrote:
> Hi all,
>
> Is there any way of getting the request.path value without having the
> request object that Django pass's around. Is there something similar
> to os.environ for the web request where I can get the path?
>
> I'm developing an app that needs to cache data on a page basis but the
> data may come from any Python code that is run for the request or it
> may come from the template layer via custom template tags. I don't
> want to have to pass the request path around in order to eventually
> pass it to my caching code for use in the cache key. I just want to be
> able to find the request path from my caching code.
>
> Possible?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Get request path without having a request object

[cootetom]

Hi all,

Is there any way of getting the request.path value without having the
request object that Django pass's around. Is there something similar
to os.environ for the web request where I can get the path?

I'm developing an app that needs to cache data on a page basis but the
data may come from any Python code that is run for the request or it
may come from the template layer via custom template tags. I don't
want to have to pass the request path around in order to eventually
pass it to my caching code for use in the cache key. I just want to be
able to find the request path from my caching code.

Possible?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Deleting sessions without Request object

[Greg Pelly]

Is it possible to log out a user manually?  The desired result is that after
I do this, the user will be forced to log in again.  I will not have an
active Request object (ie, this will be done from the admin app or a
management command, not a view).

Can I simply add the Session table to the admin app and manually delete a
user's entry?

Thanks,
Greg

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: from a template how to access the request object

[Karen Tracey]

On Wed, Jun 23, 2010 at 3:04 PM, thusjanthan <thusjant...@gmail.com> wrote:

> From a template suppose base.html in your templates how do I access
> the request object without actually passing it via the view. Cause I
> can access the user object using {{ user }} but I can't access the
> get_full_path using something like {{ request.get_full_path }}
>
> Any thoughts?
>

Sounds like you are using a RequestContext, which is the first step. That
plus having the auth context processor listed in the
TEMPLATE_CONTEXT_PROCESSORS setting would give you a template variable user.
(The auth context processor is included in the default setting value for
TEMPLATE_CONTEXT_PROCESSORS.)

The context processor that would set request is this one:
http://docs.djangoproject.com/en/dev/ref/templates/api/#django-core-context-processors-request.
That one is not in the default TEMPLATE_CONTEXT_PROCESSORS setting, so if
you want request to be set in all your templates then you'll need to add it.

Karen
-- 
http://tracey.org/kmt/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

from a template how to access the request object

[thusjanthan]

Hi all.

>From a template suppose base.html in your templates how do I access
the request object without actually passing it via the view. Cause I
can access the user object using {{ user }} but I can't access the
get_full_path using something like {{ request.get_full_path }}

Any thoughts?

Nathan.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Closures, Django Request Object, Django architecture

[Matthias Kestenholz]

On Tue, Aug 25, 2009 at 8:35 PM, Dennis Fogg<dennisf...@gmail.com> wrote:
> PS: more succinctly: status notifications can happen in many places and
> passing the session to all these places just for the status notification
> does not make the code any clearer.  Thus, I just want to access the session
> as a global variable -- how can I do that?
>

Sending messages to an user is very much tied to the current request
-- only the current request can tell you which user is active
currently, so whatever way you choose to store and retrieve
notifications (database, sessions etc) you always need the request
object in one way or the other. Really, there is a reason why Django
does not provide global (or thread local) request / user objects. If
you still want do do it, google for "threadlocals user", but I'd
advise against doing that. In the end, it's your decision though.

Btw, I've used this thread locals hack in the past, and it served me
well for some time. It came back to bite me though, and I wish I
hadn't used it; it really makes writing a testsuite a pain; dumpdata
does not work because the manager of a single model depends on a
thread local request object with an authenticated user etc. It's much
better to cope with the need of having to pass the request around than
pick up the pieces afterwards when choosing the simple path now.


Matthias



-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

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