Prefix use in reversing urls

[Bas Peschier]

Hi all,

currently the reversing mechanism for urls accepts a prefix-kwarg [1], 
which is not documented [2].

It seems like this prefix is used to prefix the entire generated url and 
make script_name possible, to which it defaults. It is not used in the 
entire code base except for tests which can directly test prefixes without 
going through set_script_name. So in basis: prefix is whatever 
get_script_name gives you.

What is curious about how Django handles it, is that it treats the prefix 
as possibly containing regular expressions [3]. Is there any history or 
documentation that this can be anything other than a valid path?

Removing that mechanism (it simplifies escaping the prefix, which was the 
original problem in #24013 [4] and a whole chain of previous tickets) 
unearths tests that don't actually test the correct thing, but overall it 
runs fine™. Since escaping the reversed url is sensitive security-wise, I 
would like a couple of eyes on it.

PR is here: https://github.com/django/django/pull/4272

Bas

[1]: 
https://docs.djangoproject.com/en/1.8/_modules/django/core/urlresolvers/#reverse
[2]: 
https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#django.core.urlresolvers.reverse
[3]: 
https://github.com/django/django/blob/master/django/core/urlresolvers.py#L448
[4]: https://code.djangoproject.com/ticket/24013

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2e77e916-62f6-4a3a-bfab-a289902236fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: App-loading reloaded - running code at startup

[Bas Peschier]

Op maandag 30 december 2013 17:16:21 UTC+1 schreef Aymeric Augustin:
>
> On 30 déc. 2013, at 13:29, Aymeric Augustin 
>  
> wrote: 
>
> [...]
>
> The real question — is requiring django.setup() acceptable? Explicit is 
> better than implicit, after all… 
>
>
As far as I can see only people who load Django outside of 
get_wsgi_application are affected and they get a pretty clear error 
message. Sounds safe enough.

I like the explicitness of django.setup() without being so explicit that it 
scares people about what magic actually happens. It also makes the path of 
understanding how Django initializes everything simpler.

What I really like is that we introduce a set point at which Django loads 
and populates everything (I am looking at all the admin-esk auto-discover 
mechanisms).

Bas

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

Declarable FormSet and friends

[Bas Peschier]

Hello everyone,

after discussion on IRC with rasca I opened up a ticket [1] about
making FormSets declarable.

We have been down this route with ModelForm and it seems to make sense
to be able to declare your FormSet somewhere instead of having to
generate it.

The idea given is you can do:

  class MyFormSet(formsets.FormSet):
can_delete = True
form = MyForm
extra = 3

This is almost possible already (BaseFormSet actually can be
subclassed if you add all the arguments to your definition), but it
might be interesting to think about the consequences. rasca is working
on extending CBV [2] which can use this.

In the mean time we looked at "removing" the factories, but for now
the admin makes good use of completely flexible generation of
ModelForm and ModelFormSets.

Ideas?

/Bas


[1]: https://code.djangoproject.com/ticket/16289
[2]: https://code.djangoproject.com/ticket/16256

-- 
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: ImportError catching in urlresolvers.py

[Bas Peschier]

For reference, I added a patch to https://code.djangoproject.com/ticket/10802
which takes Russell's approach.

-- 
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: ImportError catching in urlresolvers.py

[Bas Peschier]

On 15 jun, 07:36, Russell Keith-Magee  wrote:
> In this case, the underlying problem is that ImportError is actually
> catching 2 different errors:
>  1) The view specified doesn't exist
>  2) The module containing the view contains an error.

Agreed, in this case this information is lost in get_callable, where
the code does know the difference between 1) and 2), but the exception
raised does not convey that.

It might be a better idea to move the ViewDoesNotExist into the
get_callable function, which get triggered with an AttributeException
or an ImportError when the owning module can be imported. All other
conditions are not caught.

Bas

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