Re: Contributing Guide Request For Input

[Gabriel Hurley]

I've added a patch to ticket #14401 
based 
on the contributions people made to the wiki. This is the final call for 
comments and review before it gets officially added.

Thanks!

- Gabriel Hurley

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: r15580 breaks change list result template overwrites

[Russell Keith-Magee]

On Sunday, February 20, 2011, Sean Brant  wrote:
> Looks like r15580 modified the way change list rows are returned. The
> template used to just iterate over {{ result }} but now requires
> iteration over {{ result.row }}.  This will breaking anyones templates
> that happen to overwrite admin/change_list_results.html. Does
> overwriting admin templates fall into public api territory?

Srrictly, contrib.admin isn't covered by our backwards compatibility
policy at all - see the official docs for details [1].

That said, we try to minimize any incompatibilities, so it may be
worth taking a closer look to see if this can be done in a way that
doesn't affect the template context.

[1] http://docs.djangoproject.com/en/1.2/misc/api-stability/

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

r15580 breaks change list result template overwrites

[Sean Brant]

Looks like r15580 modified the way change list rows are returned. The
template used to just iterate over {{ result }} but now requires
iteration over {{ result.row }}.  This will breaking anyones templates
that happen to overwrite admin/change_list_results.html. Does
overwriting admin templates fall into public api territory?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A word about CSRF Protection and AJAX

[Sayane]

http://code.djangoproject.com/ticket/15354

2011/2/19 Luke Plant 

> On Sat, 2011-02-19 at 12:00 +0100, Sayane wrote:
> > There's a problem with CSRF Protection and XHR requests. It works
> > perfectly if 'csrftoken' cookie has been set already. But what if it's
> > not?
> > Cookie with token will be set only, if META["CSRF_COOKIE_USED"] is
> > True [1]. It's set to True in function get_token() [2]. get_token() is
> > called in CsrfResponseMiddleware [3] (It's deprecated, i'm not using
> > it) and in 'csrf' context processor (note - calling it is lazy, so I
> > need to use {% csrf_token %} or at least get the value of csrf_token
> > variable).
> >
> > But in my project i'm not using {% csrf_token %} anywhere. According
> > to documentation [5] I'm not required to do anything else, but write a
> > simple javascript code. Actually it's not true. I have to put
> > "request.META['CSRF_COOKIE_USED'] = True" line in every view (or write
> > appropriate decorator).
>
> > What is more, it will affect users who didn't come across page where
> > csrf_token is used, but their browser needs to send xhr post request.
>
> I guess this is an edge case - it would typically be very rare for
> someone to be doing POST AJAX requests who has never hit a page with {%
> csrf_token %} on it - even if it was just the login page.
>
> The docs for AJAX are meant to be in *addition* to the docs on the rest
> of the page, which state, among other things, that you need to include a
> {% csrf_token %} on the page. This bit (step 2 in "How to use it") could
> be clarified for the case of AJAX-only sites.
>
> So, my suggested solution is some small doc fixes, and the addition of a
> decorator 'ensure_csrf_cookie' that ensures the cookie will be sent. The
> correct way to implement this decorator is to simply add a call to
> django.middleware.csrf.get_token(). META["CSRF_COOKIE_USED"] is an
> implementation detail that we are free to change, so don't rely on
> setting that explicitly. If you would like to open a ticket to track
> this, that would be great.
>
> Regards,
>
> Luke
>
>
> --
> "Agony: Not all pain is gain." (despair.com)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A word about CSRF Protection and AJAX

[Luke Plant]

On Sat, 2011-02-19 at 12:00 +0100, Sayane wrote:
> There's a problem with CSRF Protection and XHR requests. It works
> perfectly if 'csrftoken' cookie has been set already. But what if it's
> not?
> Cookie with token will be set only, if META["CSRF_COOKIE_USED"] is
> True [1]. It's set to True in function get_token() [2]. get_token() is
> called in CsrfResponseMiddleware [3] (It's deprecated, i'm not using
> it) and in 'csrf' context processor (note - calling it is lazy, so I
> need to use {% csrf_token %} or at least get the value of csrf_token
> variable).
>
> But in my project i'm not using {% csrf_token %} anywhere. According
> to documentation [5] I'm not required to do anything else, but write a
> simple javascript code. Actually it's not true. I have to put
> "request.META['CSRF_COOKIE_USED'] = True" line in every view (or write
> appropriate decorator).

> What is more, it will affect users who didn't come across page where
> csrf_token is used, but their browser needs to send xhr post request.

I guess this is an edge case - it would typically be very rare for
someone to be doing POST AJAX requests who has never hit a page with {%
csrf_token %} on it - even if it was just the login page.

The docs for AJAX are meant to be in *addition* to the docs on the rest
of the page, which state, among other things, that you need to include a
{% csrf_token %} on the page. This bit (step 2 in "How to use it") could
be clarified for the case of AJAX-only sites.

So, my suggested solution is some small doc fixes, and the addition of a
decorator 'ensure_csrf_cookie' that ensures the cookie will be sent. The
correct way to implement this decorator is to simply add a call to
django.middleware.csrf.get_token(). META["CSRF_COOKIE_USED"] is an
implementation detail that we are free to change, so don't rely on
setting that explicitly. If you would like to open a ticket to track
this, that would be great.

Regards,

Luke


-- 
"Agony: Not all pain is gain." (despair.com)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Adding new buttons like delete and change in the admin changelist_view

[Jonas Obrist]

It is indeed a wonderful and powerful thing, and luckily a thing that's 
already possible! Just edit the changelist_view template.

For an example please have a look 
at 
https://github.com/joshourisman/django-tablib/blob/master/django_tablib/templates/tablib/change_list.html

Jonas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Run in Aptana

[Karen Tracey]

Please ask questions about using Django on the django-users list. The topic
of this list is the development of Django itself.

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bound formset.empty_form after posting formset

[Hidde-Jan Jongsma]

Hi Carl,

I made a ticket and provided a patch + test. I have not yet checked the
behavior in django.contrib.admin, but since the formclass is initialized
with empty_permitted=True, the admin will *probably* not be affected, since
it would deal with empty forms but without errors.

This is the ticket: http://code.djangoproject.com/ticket/15349

Thanks,

HJ

On Sat, Feb 19, 2011 at 4:03 AM, Carl Meyer  wrote:

> Hi Hidde-Jan,
>
> On Feb 18, 10:20 am, Hidde-Jan Jongsma  wrote:
> > Lately, I've been working a lot with Django's modelformsets in
> > combination with javascript. The BaseFormSet implements a handy method
> > _get_empty_form, accessible through the empty_form property. This
> > method checks whether formset.is_bound is True, and if it is, updates
> > the kwargs passed to the formclass with the supplied data and files.
> >
> > This behaviour strikes me as odd. It results in a form that can no
> > longer be considered empty, but is bound and, possibly, can contain
> > errors. Of course, this only happens *after* the formset has been
> > posted. As a result, a formset.empty_form can no longer be used as a
> > (javascript) template for creating new forms on the client side, since
> > it is unpredictable.
> >
> > Is there a specific reason that it was implemented in this way? In my
> > opinion, an unbound empty_form would make much more sense.
>
> I agree with you. I can't see any reason why the empty_form for a
> bound formset should be any different than for an unbound one. The
> intended use for empty_form is as a template for Javascript add-
> another behavior, and such a template should always be a predictably
> empty form with no errors.
>
> If you can file a bug on this, that'd be great. If you can provide a
> patch with tests, double-great. If you can also confirm that it has no
> negative impact on the admin's use of formsets (or that this problem
> is present in the admin currently and this fixes it), triple-great ;-)
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Django Run in Aptana

[Andreas Rudischhauser]

Hello, 

i'm trying to get Django running in Aptana Studio. I've got PyDev installed and 
can create a new project. The point that's missing is the "run as". Does 
anybody know how to setup a run configuration.
(Im running it on mac, if that's important to know). Or is there a better dev 
environment to develop for django?

Regards
Andi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bound formset.empty_form after posting formset

[Hidde-Jan Jongsma]

(sorry if this shows up twice)

Hi Carl,

I made a ticket and provided a patch + test. I have not yet checked
the behavior in django.contrib.admin, but since the formclass is
initialized with empty_permitted=True, the admin will *probably* not
be affected, since it would deal with empty forms but without errors.

This is the ticket: http://code.djangoproject.com/ticket/15349

Thanks,

HJ

On Feb 19, 4:03 am, Carl Meyer  wrote:
> Hi Hidde-Jan,
>
> On Feb 18, 10:20 am, Hidde-Jan Jongsma  wrote:
>
> > Lately, I've been working a lot with Django's modelformsets in
> > combination with javascript. The BaseFormSet implements a handy method
> > _get_empty_form, accessible through the empty_form property. This
> > method checks whether formset.is_bound is True, and if it is, updates
> > the kwargs passed to the formclass with the supplied data and files.
>
> > This behaviour strikes me as odd. It results in a form that can no
> > longer be considered empty, but is bound and, possibly, can contain
> > errors. Of course, this only happens *after* the formset has been
> > posted. As a result, a formset.empty_form can no longer be used as a
> > (javascript) template for creating new forms on the client side, since
> > it is unpredictable.
>
> > Is there a specific reason that it was implemented in this way? In my
> > opinion, an unbound empty_form would make much more sense.
>
> I agree with you. I can't see any reason why the empty_form for a
> bound formset should be any different than for an unbound one. The
> intended use for empty_form is as a template for Javascript add-
> another behavior, and such a template should always be a predictably
> empty form with no errors.
>
> If you can file a bug on this, that'd be great. If you can provide a
> patch with tests, double-great. If you can also confirm that it has no
> negative impact on the admin's use of formsets (or that this problem
> is present in the admin currently and this fixes it), triple-great ;-)
>
> Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

A word about CSRF Protection and AJAX

[Sayane]

There's a problem with CSRF Protection and XHR requests. It works perfectly
if 'csrftoken' cookie has been set already. But what if it's not?
Cookie with token will be set only, if META["CSRF_COOKIE_USED"] is True [1].
It's set to True in function get_token() [2]. get_token() is called in
CsrfResponseMiddleware [3] (It's deprecated, i'm not using it) and in 'csrf'
context processor (note - calling it is lazy, so I need to use {% csrf_token
%} or at least get the value of csrf_token variable).

But in my project i'm not using {% csrf_token %} anywhere. According to
documentation [5] I'm not required to do anything else, but write a simple
javascript code. Actually it's not true. I have to put
"request.META['CSRF_COOKIE_USED'] = True" line in every view (or write
appropriate decorator).

What is more, it will affect users who didn't come across page where
csrf_token is used, but their browser needs to send xhr post request.

It affects svn version. I don't know if other versions are affected.

[1]
http://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py#L236
[2]
http://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py#L67
[3]
http://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py#L270
[4]
http://code.djangoproject.com/browser/django/trunk/django/core/context_processors.py#L38
[5] http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: pb with search on website

[Jacob Kaplan-Moss]

On Fri, Feb 18, 2011 at 7:04 AM, Will Hardy  wrote:
> In case there's any confusion in the question, it appears as if adding
> a period or braces to a word makes it impossible to be found, even
> when the exact string exists in the documentation:
>
> * http://docs.djangoproject.com/search/?q=get&release=4
> * http://docs.djangoproject.com/search/?q=get()&release=4
> * http://docs.djangoproject.com/search/?q=get(&release=4
>
> I know nothing about your search system, but perhaps there's some
> inconsistent tokenising going on?

Ahha, thanks -- that's the bit I was missing. I think it's probably
something weird that Xapian's doing, but it's easy to work around.
Thanks!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.