Re: Proposal: Add a "lookup" attribute to SelectObjectMixin

[Andrew Ingram]

On 26 Dec 2011, at 19:01, Andre Terra wrote:

> I propose we add a "lookup" attribute which defaults to "__exact" (for 
> backwards-compatibility as well as avoiding surprises) and is combined with 
> slug_field in the filter call so that users can customize the filter kwarg in 
> an elegant fashion. Before reading the source code carefully, I had written 
> my own mixin that just used string formatting (i.e. "%s_%s" % (slug_field, 
> lookup)") to handle this, and I liked how it looked. I am, however, more than 
> willing to take a different route should anyone suggest it.
> 
> Another solution would be to keep the current code as is, and just add a note 
> in the docs regarding the flexibility of slug_field. Given that the attribute 
> name does say *field*, I'm not too fond of this approach.
> 
> 
> Again, I'm willing to hear any feedback on this matter, as well as writing 
> patches and tests, as I expect them to be quite simple and therefore within 
> my abilities.
> 
> 
> 
> Cheers,
> 
> André Terra (airstrike)

Hi André

I'm trying to understand what your use case would be. SingleObjectMixin is 
designed to only ever give you one object back (though I'm surprised it doesn't 
handle the MultipleObjectsReturned exception), so out of all the lookup choices 
we have, only an exact match on a unique field makes sense. Am I missing 
something here?

Regards,
Andrew Ingram

-- 
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: Moving to ... Github vs Bitbucket

[Andrew Ingram]

On 16 February 2012 15:42, Łukasz Rekucki  wrote:
> 1) I can't argue about popularity, because I have no data, but most
> Django applications I use come from github, so it's also quite
> popular.
>
> 2) I don't think Django should care if the collaboration tool runs
> python/django or java/grails as long as it's useful for developers.
> Anything beyond that is politics and that's what DSF might care about
> (I don't).
>
> 3) As for similar features... sometimes "similar" is not enough. I'm
> not a regular Bitbucket user, so I maybe just didn't discover that,
> but how can you add per line comments in patches on Bitbucket ?
> Without that, code reviews for non-trivial patches is a real PITA.

Speaking from my own subjective tastes, I much prefer the experience
of using Github over Bitbucket. Simple things like showing the source
tree on a project's homepage make far more sense to me than showing
the latest commit messages. If I'm looking for how something works in
Django, the first thing I do is go to the github repo and browse the
source code.

Additionally, almost every library I use as a dependency can be found
on Github, and familiarity is a very useful tool. South is the only
significant exception to this.

Regards,
Andy

-- 
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: FormMixin success_url should accept callable

[Andrew Ingram]

Hi Martin,

There are (as of Django 1.4) already two solutions to this:

1 - override get_success_url(). the default behaviour of this method is to just 
return self.success_urll, but obviously it can be modified to return whatever 
you like

2 - use reverse_lazy (Django 1.4)  instead of reverse to delay the evaluation 
until after the urlconf has been initialised.

I don't think there's a real benefit to having a third approach.


Regards,
Andrew Ingram


On 8 Apr 2012, at 22:12, Martin Tiršel wrote:

> Hello,
> 
> I just started to use class based views and I came to the CreateView and 
> success_url argument. This argument has to be string what leads to typing 
> URLs in views instead of using reverse() function (you have no access to urls 
> through reverese() in view initialization). I think (if there is no better 
> way) that this parameter should accept callable too and something like this 
> would be possible:
> 
> class MyView(CreateView):
>success_url = lambda: reverse(
>'foo:bar'
>)
> 
> Should I create a feature request ticket or should I read the docs more 
> carefully? :)
> 
> Kind regards,
> Martin Tirsel
> 
> -- 
> 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: Allowing formsets to contribute kwargs to forms they create

[Andrew Ingram]

I've had the need for this quite frequently, Whenever I'm using a
custom form class with modelformset_factory I almost always end up
having to define a custom formset class that does nothing except pass
an extra kwargs (usually user) to each form.

It looks like your approach only adds this facility to BaseFormSet, I
think the formset factories will need to hook into it as well.

Regards,
Andrew Ingram


On 24 April 2012 14:55, Tom Evans  wrote:
> Hi all
>
> I raised a ticket about this new feature, with patch:
>
> https://code.djangoproject.com/ticket/18166
>
> I'd quite like to quickly either complete this or dump the idea.
>
> Opinions?
>
> Cheers
>
> Tom
>
> --
> 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: Suggestion: make auth login view more dynamic

[Andrew Ingram]

It seems to me there'd be more mileage in making new class-based
versions of the auth views.

- Andy

On 24 May 2012 13:51, Florian Apolloner  wrote:
> Hi,
>
> -1 from me here.
>
> A) why don't you have site_name_name etc (those are still fixed).
> B) templates need to be able to rely on a name, if your template expects a
> different name user {% with form as my_form %}
>
> Cheers,
> Florian
>
>
> On Wednesday, May 23, 2012 1:02:53 PM UTC+2, Hedde van der Heide wrote:
>>
>> I couldn't find an existing ticket but I'd like to suggest a change to
>> make the basic auth view more dynamic (I'm not fond of hardcoded context
>> variables :-))
>>
>> change:
>>
>> def login(request, template_name='registration/login.html',
>>           redirect_field_name=REDIRECT_FIELD_NAME,
>>           authentication_form=AuthenticationForm,
>>           current_app=None, extra_context=None):
>>
>> to:
>>
>> def login(request, template_name='registration/login.html',
>>           redirect_field_name=REDIRECT_FIELD_NAME,
>>           authentication_form=AuthenticationForm,
>>           current_app=None, extra_context=None, form_name='form'):
>>
>>
>> and obviously:
>>
>>     context = {
>>         form_name: form,
>>         redirect_field_name: redirect_to,
>>         'site': current_site,
>>         'site_name': current_site.name,
>>     }
>>
>>
>> Kind Regards,
>>
>> Hedde van der Heide
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/9xWEYMsvTU8J.
>
> 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: RFC: More class based views, take two

[Andrew Ingram]

Hi Iván,

I'd temporarily given up on getting extra_views into Django because of
a blocking issue with pagination and formsets.

Assuming a goal is to be able to build a new admin using class-based
views, there is a prerequisite of being able to paginate, sort and
filter on the querysets used for modelformsets. The problem is that
with Django's class-based views as they are, pagination is handled at
the template context stage of the logic, whereas the formsets are
instantiated and validated much earlier. I had raised a ticket about
fixing this, but it was closed as wontfix because it would almost
certainly introduce backwards-incompatible changes

On a related now, you mentioned that none of the libraries you've
mentioned are sufficiently polished. What further work do they need?
As I see it, my main omission right now is documentation, though that
is in progress.

Regards,
Andy



On 27 May 2012 21:54, Iván Raskovsky  wrote:
> The generic class based views were introduced in 1.3, since then they
> haven't seen much love. I feel the most wanted missing views are the
> formsets related ones (specially the inline_formsets related ones).
>
> I've written to the list some months ago[0] with no reply. Luckily I'll
> get more traction this time. Several projects have popped up[1, 2, 3] to
> cover this area. Each one has different approaches.
>
> Ticket #16256[4] is tracking this changes
>
> * enhanced_cbv[0] *
>
> Tries to maintain a similar API to the existing views and the admin
> inlines. Creates three generic views for a multiple formsets view, multiple
> model_formsets view and a model with multiple inline_formset view. Joins
> the update and create views in one view.
>
> * extra-views[1] *
>
> Keeps the current API as much as possible adding views for a one formset
> and for one model_formset and adds views for working with
> inline_formsets and generic inline_formsets.
>
> * cbv_utils[2] *
>
> I haven't played much with this one yet, but it only adds a view to work
> with inline_formsets. It also proposes changes to the existing CVB APIs
> to simplify adding this views[5].
>
> Another related ticket is #10403[6]: a declarative syntax to define
> FormSets so we don't need a special wrapper around the factories
> simplifying creating inlines in a similar fashion as the admin's
> InlineModelAdmin.
>
> So, we have 3 tested and working alternatives for these views. I think
> none of them is polished enough as for inclusion to core.
>
> I have no idea how to move forward. Right now it seems kinda stalled.
> Should we pick one implementation and start moving forward with that
> one? If so, which one? Should we start a wiki page discussing the
> different API decisions we need to make?
>
> I think we have the manpower to make this possible, the three
> implementations shows people really need this in their projects and I'm
> more than willing to spend time working on this.
>
> Any feedback will be greatly appreciated,
>    Iván
>
> [0] https://groups.google.com/d/msg/django-developers/aWRDIwDKDG8/gW3RGurxoZoJ
> [1] https://github.com/rasca/django-enhanced-cbv
> [2] https://github.com/AndrewIngram/django-extra-views/
> [3] https://github.com/tswicegood/cbv_utils
> [4] https://code.djangoproject.com/ticket/16256
> [5] https://code.djangoproject.com/ticket/17557
> [6] https://code.djangoproject.com/ticket/10403
>
> --
> 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: Draft branch: Swappable User models in contrib.auth

[Andrew Ingram]

On 4 June 2012 16:12, Russell Keith-Magee  wrote:
>  * The swapping mechanic is set up using a new Meta option on models
> called 'swappable' that defines the setting where an alternate model
> can be defined. Technically, the swappable option *could* be used for
> any model; however, I'm not proposing that we actually document this.
> I've implemented it as a generic approach purely to make the internals
> cleaner -- mostly to avoid needing to make references to auth.User in
> the model syncdb code, and to make testing possible (i.e., we can do
> validation tests on a dummy 'swappable' model, rather than trying to
> munge a validation test for auth.User specifically).

I like the idea of a 'swappable' option, but I can see some potential
issues with the implementation. I'm one of the developers of Oscar
(https://github.com/tangentlabs/django-oscar/) and providing a clean
method to for overriding models has been a major pain point. One of
our key requirements is that any model in Oscar may be overridden, to
that end every model has both abstract and concrete versions (much
like your implementation of AbstractBaseUser and User).

Our current way of handling overrides is for every reference to a
model in Oscar to use get_model rather than the explicit classname.
But this does end up causing some ugly things like this:

from oscar.apps.catalogue.abstract_models import AbstractProduct

class Product(AbstractProduct):
# stuff

from oscar.apps.catalogue.models import *


Issues:
1) The override model HAS to have the same name as the default model,
otherwise get_model('catalogue', 'Product') won't work.
2) We have to import all the remaining default models after we declare
our overrides. But this only works because Django's model metaclass
prevents the default Product replacing the one we've just defined. I
don't like this because it's a little bit magic.
3) You have to remove Oscar's version of the app from INSTALLED_APPS
and replace it with your own. Actually, technically you don't. If you
leave Oscar's app installed but put your own one ('foo.catalogue') in
front of it, you can even get rid of the nasty import * thing - but
again, more magic. (Aside: you can actually use this approach already
to override Django's User model, because the metaclass means any
references to Django's User will be replaced with references to your
own. )

I had investigated using a class decorator to handle overrides:

@replace_model('catalogue.Product')
class MyProduct(AbstractProduct):
# foo

But this got seriously complicated because the metaclass modifies the
class before the decorator can be applied, so I was looking into ways
to sever all the ties with the app cache before I went insane and gave
up.

Back to my main points... Your swappable option would solve quite a
lot, in the case of the User model it's ideal. But I'm concerned that
if people start using it more widely we'd end up having dozens of new
settings that would get quite silly in the case of a large project
like Oscar. I think it's important that overrides can be defined in
the settings file, but I'd also like to see it possible at model
definition time, either using a decorator (like above) or a Meta
option like 'replaces'. The risk, of course, is that it means any
third-party app could override any other model without you necessarily
being aware of it, not sure how this would be mitigated.

If I've not made much sense let me know, I've always found it hard to
articulate on this particular topic.


Regards,
Andrew Ingram

-- 
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: Proposed Field API additions

[Andrew Ingram]

On 7 June 2012 18:17, Andrew Godwin  wrote:
> This means either having to register custom fields (like admin classes,
> for example), or requiring fields to live in a fields.py or fields
> package (like models and models.py). This is to provide for a
> less-fragile way of referring to them than their full module path (which
> might change based on project name or package location).
>
> Neither of these two options is perfect - registration means a little
> more "boilerplate" code, while requiring them to be in a certain module
> is going to hurt apps that don't have them there already. For that
> reason, I prefer the registration approach - it will only be one extra
> line per field, it's a pattern already used for admin classes and
> filters/tags, and it will allow for field classes to be renamed while
> keeping the same registered name (if someone wants).

I prefer the registration approach because it's more explicit. But
there's also the third option of using both, auto-register anything in
fields.py but allow explicit registration for anything found
elsewhere.

- Andy

-- 
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: Proposal: Signal connection via "my_app.MyModel"

[Andrew Ingram]

I can see a use case for this, but would this not work?

from django.db.models import get_model

post_save.connect(

my_signal_handler,

sender=get_model('my_app', 'MyModel'),
)

As long as the app cache has been initialised before you call get_model,
this should work fine.

- Andy


On 22 August 2012 06:17, Yo-Yo Ma  wrote:
> Is there anyone else out there who doesn't like having to import models
from app X into app Y just so that app Y can connect post save signals to
them?
>
> --
> You received this message because you are subscribed to the Google Groups
"Django developers" group.
> To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/_vcka4fdtPUJ.
> 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: Model inheritance extended.

[Andrew Ingram]

On 25 September 2012 17:45, Alex Ogier  wrote:

> There's a big thing you cannot do without grouping models: you can't have
> an abstract base class relate to another abstract base class. Django's
> foreign key mechanism doesn't know how to relate to a to-be-instantiated
> concrete class.
>

Not entirely true, the foreign key can use a string 'app.Model', we've used
this mechanism quite extensively in Oscar (an e-commerce) platform to allow
overriding or extending of any model without having to change the code for
other models. That said, we have to do some quite ugly tricks to get this
working properly.  I'm intrigued by this ModelFactory approach because it
can potentially remove some of our hacks, but I'm not overly keen on
adopting an new idiom that isn't widely accepted as a good approach. So I'm
following this discussion with interest.

- Andy Ingram

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

Add a "split" field to a model causes problems

[Andrew Ingram]

Hi all,

This one stung me today. Basically as part of an event (calendar) app, I 
have functionality for splitting a series of events into two at a given 
timestamp. The details aren't particularly relevant, but the key thing is 
that I had a method called "split" on one of the models.

This was working fine until I tried to add a ManyToManyField to the same 
model, at which point it through a rather ugly error during initialisation 
of the apps.

django/db/models/fields/related.py line 56, in add_lazy_relation
> app_label, model_name = relation.split(".")
> TypeError: unbound method split() must be called with RecurringEvent 
> instance as first argument (got str instance instead)


Because I had no knowledge of the inner workings here, this error wasn't 
helpful until pdb told me that `relation` was an instance of my model. The 
issue is that in this point in the code, relation can either be a model or 
a string 'app_label.model_name', so it's using the presence of a split 
function to determine which it is, me having a split function on my model 
breaks this check. Having a non-callable 'split' causes a similar problem, 
just with a different exception.

Long story short, adding a 'split'  method to my model caused the 
inner-workings of Django to break, I think the documentation should provide 
a list of attribute names that can't be added to a Django model without 
breaking things, though this is the first time I've ever come across such a 
problem so it might be a one-off.

Regards,
Andrew Ingram

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/0A23Ye0xgcQJ.
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: Add a "split" field to a model causes problems

[Andrew Ingram]

Hi Mike,

It looks like I missed part of the problem, namely that abstract models are 
involved. These model definitions should trigger the error:

> from django.db import models
> 
> 
> class Bar(models.Model):
>   name = models.CharField(max_length=250)
> 
> 
> class AbstractFoo(models.Model):
>   name = models.CharField(max_length=250)
>   bars = models.ManyToManyField(Bar)
> 
>   def split(self):
>   pass
> 
>   class Meta:
>   abstract = True
> 
> 
> class Foo(AbstractFoo):
>   pass


It doesn't make a difference if the ManyToManyField is on the abstract model or 
the concrete one.

Regards,
Andrew


On 4 Nov 2012, at 20:42, Mike Johnson  wrote:

> Hi Andrew,
> 
> I'm trying to come up with a test case for this and am struggling to 
> reproduce the problem in test.
> 
> Can you post some code to help us reproduce it?
> 
> Thanks,
> Mike
> 
> 
> On Tuesday, October 23, 2012 3:52:10 AM UTC-7, Andrew Ingram wrote:
> Hi all,
> 
> This one stung me today. Basically as part of an event (calendar) app, I have 
> functionality for splitting a series of events into two at a given timestamp. 
> The details aren't particularly relevant, but the key thing is that I had a 
> method called "split" on one of the models.
> 
> This was working fine until I tried to add a ManyToManyField to the same 
> model, at which point it through a rather ugly error during initialisation of 
> the apps.
> 
> django/db/models/fields/related.py line 56, in add_lazy_relation
> app_label, model_name = relation.split(".")
> TypeError: unbound method split() must be called with RecurringEvent instance 
> as first argument (got str instance instead)
> 
> Because I had no knowledge of the inner workings here, this error wasn't 
> helpful until pdb told me that `relation` was an instance of my model. The 
> issue is that in this point in the code, relation can either be a model or a 
> string 'app_label.model_name', so it's using the presence of a split function 
> to determine which it is, me having a split function on my model breaks this 
> check. Having a non-callable 'split' causes a similar problem, just with a 
> different exception.
> 
> Long story short, adding a 'split'  method to my model caused the 
> inner-workings of Django to break, I think the documentation should provide a 
> list of attribute names that can't be added to a Django model without 
> breaking things, though this is the first time I've ever come across such a 
> problem so it might be a one-off.
> 
> Regards,
> Andrew Ingram
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-developers/-/95Ok89lqNjkJ.
> 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: URL dispatcher fallthrough?

[Andrew Ingram]

The approach we take at work is to have a view that wraps around the
product, category and occasion views and takes care of the fallthrough
logic. I'm not a fan of this approach, because it means that you can't just
look at the urlconf and see which pattern maps to which view function. On
the other hand, I don't think your solution would solve this either, you'd
end up having 3 patterns that could all match, making it non-obvious what
the behaviour is.

Obviously the ideal solution is to scope URLs correctly to avoid all this
in the first place, but I've found that in the real world this is easier
said than done. So it would be nice to have an idiomatic solution.

An alternative might be a kwarg on the url function, such as
'fallthrough_on_404'. But it all feels a bit hackish to me :/

Regards,
Andy


On 18 March 2013 15:23, julianb  wrote:

> Hi,
>
> imagine the following use case:
>
> You build an online store where you have sorted products into several
> categories and maybe associated an occasion. Now you want to build URLs. So
> the URL schema that all of the store's owners agree on is:
>
> //
> //
> //
>
> Look simple.
>
> Because product slugs should generally be different to category slugs and
> occasions, you expect no clashes here. And you don't want to bloat the URLs
> by putting product/ and category/ in there. And you also do not want to
> resort making it look cryptic by having just /p// and so on.
> Then it comes to Django. How do you do that?
>
> Well, at the moment, as far as I am aware, you can't. The first URL will
> match everything all the time, not giving the other views a chance to kick
> in.
>
> So I propose some kind of URL fallthrough. The view could do
>
> raise UrlNotMatched
>
> and the dispatcher goes to the next possible matching view.
>
> Would that be good? Any thoughts?
>
> --
> 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: javascript view for named urls

[Andrew Ingram]

On 29 Mar 2013, at 17:22, Bernhard Ja  wrote:

> Hello together,
> this is my first post to the Django developers list. Please let me know if 
> this topic is better placed on Django users :-)
> 
> For i18n there is a javascript_catalog view we can use to access translations 
> in javascript.
> Accessing django urls in javascript is IMHO an annoying task, but it cloud be 
> as simple as the translation thing.
> 
> I wrote a small django app[1] that makes url handling easy for me.
> I would love to see sth. like that in the django core.
> 
> What's your opinion? 
> 
> Thanks for feedback and have a nice day,
> Boerni
> 
> [1] https://github.com/version2/django-js-reverse

I like the concept of this, because it's something I've often wanted myself. 
But I want to bring up a couple of points:

1) Some websites rely on the obscurity of some of their URLs as an additional 
security measure (i.e. have the admin at something other than /admin/). This is 
admittedly not a great measure, since a persistent attackers will probably get 
around it. But the key would be a way to manage which patterns get included in 
the javascript catalog, possibly even having it configurable at the the view 
level so that some templates can request a different subset of the patterns to 
others.

2) It'd be nice if it could be integrated with internationalisation, so that if 
you're using Django's i18n_patterns, the view automatically fills in the 
country segment based on the request's locale. Much like the translation string 
view only returns the strings for the request's language.

Andy

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

Re: Enhance class Storage with additional methods

[Andrew Ingram]

On 10 April 2013 14:56, Javier Guerra Giraldez  wrote:
> check django-storages
> http://django-storages.readthedocs.org/en/latest/  it includes several
> storage backends, S3 among them.
>
> --
> Javier

I think he was asking whether the storage API should be extended to
support additional operations, namely "move" and "copy". I imagine he
already has an s3 storage backend.

I can see how such methods would be useful, but I'd also be a little
wary of going too far down the road of building an entire filesystem
abstraction API.

Andy

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

Re: Proposal: Redefine specific {% block %} in an intermediate template

[Andrew Ingram]

I've been wanting this exact feature for years. I've always struggled to
explain the problem, but I've had numerous cases where this would have made
for a vastly simpler template structure.

Big +1 from me.


On 17 April 2013 16:50, Emil Stenström  wrote:

> Hi,
>
> Proposal:
> Make it possible to use the same template block name twice, if the second
> one is nested within the first one. Inheriting from the template fills in
> the innermost block.
>
> --
> Background (why is this useful?):
> Say you have one base.html template defining a {% block content %}, and
> ten templates inheriting from it and defining the contents of the block.
> Now you decide that five of those templates actually should have a warning
> message at the top, and you decide to make a new base_with_warning.html
> template. You should should now be able to just change what block five of
> the templates inherit from, add the warning to your new base template, and
> be done with it?
>
> Not really. Your base_with_warning.html would have to look like this:
>
> {% extends "base.html" %}
> {% block content %}
> Be careful when changing these settings!
> {% block content %}{% endblock %}
> {% endblock %}
>
> And this doesn't work in Django because duplicate block names are not
> allowed. I think making this possible would make cases like the one I'm
> describing above much easier to handle.
>
> --
> Alternatives (this is how you should solve it instead...):
> There are other ways to solve the problem I'm describing above. Let me
> list a few and talk about the problems I see with them:
>
> 1) Create a new template block in base_with_warning.html and change the
> five templates to use that block instead.
>
> Problem: This puts the burden on developers to remember all kinds of
> content blocks they have in this project, and change them depending on what
> template they happen to be inherit from. The interface to the developer
> working on a new child template is much cleaner if they know they can
> always use the content block, and that the template they inherit from with
> handle the rest.
>
> 2) Make a child templates call super, and put the warning div inside the
> content block in base_with_warning.html.
>
> Problem: It's very easy to forget calling super when making a new
> template. It quickly becomes repetitive to type block.super in each of the
> templates. Should I call super in the five templates without a warning too?
> Just to be sure it isn't forgotten if someone changes the inherited
> template.
>
> 3) Use an include tag in each of the child templates instead of inheriting.
>
> Problem: This is just as repetitive as copy-pasting the div to each of the
> subtemplate, it's just the {% include "warning.html" %} is a shorter string
> to copy-paste. As with all copy-paste, it makes it easy miss one instance
> when changing the others. Not maintainable.
>
> 4) Use a template variable to decide whether to render the warning or not.
>
> Problem: This moves the copy-paste to the view logic. Now I need to
> remember to pass the right variable in the view instead, with the same
> problem as with copy-paste above.
>
> 5) Write a custom template tag that does what I want.
>
> Problem: I really don't know how to do this, and I haven't found someone
> that has written a tag like that after are plenty of googling.
>
> --
> Backwards compatibility (this will not break stuff!):
> Since duplicate block names are not allowed today, this change would be
> 100% backwards compatible. Everything would continue working as it always
> has.
>
> --
> FAQ:
> a) How would you inherit from a template with duplicate blocks with the
> same name? This proposal only deals with the case where the first block is
> defined inside the second block. If this happens the child templates
> content should fill the INNER block, not the outer one. There would be no
> way to override the outer block, since that would be shadowed by the
> redefined inner block.
>
> b) If we allow for multiple blocks with the same name, what should happen
> with two blocks side by side (not nested)? We wouldn't allow that. This
> proposal is only about duplicate blocks when nested inside eachother. All
> other duplication would still yield the same error.
>
> c) I have another suggestion that solves your problem without the problems
> with 1) - 5) above, that doesn't require a change in django? That really
> isn't a question, but fine :) Bring it on! I'm really interested in solving
> the problem described in the background section in a clean way, not a
> particular tech solution.
>
> d) Do other people have this problem? I've found a few:
> http://stackoverflow.com/questions/15448211/django-template-block-overriding/-
> http://stackoverflow.com/questions/8717521/django-multi-level-template-extends-and-nested-blocks-
>  This could also be used to handle nicely breadcrumbs in multiple levels.
> You can proba

Re: Proposal for simplifying part of the GCBV API slightly.

[Andrew Ingram]

The original use case for pk_url_kwarg and slug_url_kwargs was something
like this:

/(?P[\w-]*)/ - DetailView
/(?P[\w-]*)/another-resource/ - Scoped ListView
/(?P[\w-]*)/another-resource/(?P[\w-]*) - Scoped
DetailView

In this case, the Scoped ListView and Scoped DetailView would both inherit
a mixin that overrides get_queryset(), and the Scope DetailView would just
set "slug_url_kwargs = 'another_slug'"

I've used some variant of this pattern on almost every project I've been
involved with that utilises class-based views, including some frameworks,
so I don't think this edge case is quite as edgy as it might seem at first.

However, I do agree that your simplification is an improvement. I've done a
lot with CBVs since I first suggested the URL kwarg overrides, and I think
it's better to have less configurable fields and focus instead on having
good entry points into customising the classes through method overrides.


Andy



On 22 April 2013 13:33, Tom Christie  wrote:

> Hi Calvin,
>
> I can think of a few reasons.
>> - you've changed models or fields internally through migrations, but need
>> to continue supporting old URLs.
>> - you don't like the internal name to be exposed
>> - you have different models but want to expose a consistent URL pattern.
>
>
> Those attributes control the URL kwargs that are used in the regex, we're
> not talking about URL query parameters or anything else that's visible to
> the end-user.  Internal names aren't being exposed anywhere, and there'd be
> no issue with updating field names and continuing to support the URLs that
> reference them.
>
> Having said that, you're probably correct that I've overstated point (1) -
> There might be some circumstances where the developer would prefer to use
> 'slug' as the regex kwarg, but look up against a differently named model
> field.  I'd still think that there's a very strong argument to be made that
> we could consider that a corner case that requires overriding `get_object`,
> in exchange for having a simpler API for the standard case.
>
> There would of course be other alternatives such as using both
> `lookup_field` and `lookup_kwarg` with the later defaulting to the same as
> the former if unset, but I'm not wild about something like that given that
> the intention of this proposal is to try to slightly slim down an aspect of
> the API.
>
>
> On Monday, 22 April 2013 12:37:32 UTC+1, Calvin Spealman wrote:
>>
>>
>> On Apr 22, 2013 7:15 AM, "Tom Christie"  wrote:
>> >
>> > I'd be interested to know what you folks think of this proposal.
>> >
>> > SingleObjectMixin currently exposes these three attributes and one
>> method all dealing with queryset filter arguments...
>> >
>> > * pk_url_kwarg = 'pk'
>> > * slug_field = 'slug'
>> > * slug_url_kwarg = 'slug'
>> > * get_slug_field()
>> >
>> > I was wondering if it would be worth considering simplifying the API
>> somewhat, by moving those three attributes, and that method, into a
>> PendingDeprecation state, and replacing their usage with a single attribute
>> instead, that is used both as the URL kwarg, and as the queryset filter.
>> >
>> > * lookup_field = 'pk'
>> >
>> > That'd (eventually) lead to a simpler get_object implementation
>> internally, and (immediately) present a slightly nicer, simpler API.
>> >
>> > It'd be marginally different in that slug based lookups would require
>> an explicit `lookup_field = 'slug'` to be added to the view,
>> > and also in that it wouldn't handle the case of `slug_field` being set
>> to a different value from `slug_url_kwarg`.
>> >
>> > Personally I don't see the later being an issue as:
>> >
>> > 1. It's not clear to me why you'd ever *need* to use a URL kwarg that's
>> not the same as the filter arg.
>>
>> I can think of a few reasons.
>> - you've changed models or fields internally through migrations, but need
>> to continue supporting old URLs.
>> - you don't like the internal name to be exposed
>> - you have different models but want to expose a consistent URL pattern.
>>
>> > 2. If it's really something you need to do, then overriding get_object
>> is still really simple, as well as being nice and explicit...
>> >
>> > get_object(self, queryset):
>> > if queryset is None:
>> > queryset = self.get_queryset()
>> > return get_object_or_404(queryset, ...) # whatever custom
>> lookup behavior you need.
>> >
>> > To me, the main trade-off seems to be - Is the resulting API enough of
>> an improvement to be worth the change?
>> >
>> > Any opinions?
>> >
>> >   Tom
>> >
>> > As an aside, is the discussion group considered the correct place for
>> API-changing proposals like this, or should I just raise them straight to
>> the ticket tracker?
>> >
>> > --
>> > 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-develop...@**googlegroups.com.
>> > To post to this

Re: Django 1.6 release timeline

[Andrew Ingram]

On 30 Apr 2013, at 23:38, Shai Berger  wrote:
> I see one issue with this: According to current procedures, if this timeline 
> is followed, support for 1.4 will be dropped less than 6 months after the 
> release of 1.5. At least for some of us (which, as I mentioned earlier on the 
> list, only moved to 1.4 when the 1.5 release forced us to), this may be a bit 
> of a problem.
> 
> Shai.

It seems like 1.4 support might need to be extended. I'm assuming that given 
the success of the kickstarter campaign, Andrew's schema migration 
functionality will be made available to 1.4, and the functionality seems to be 
a prerequisite for migrating to the new way of handling user models.

Andy

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

Re: Django 1.6 release timeline

[Andrew Ingram]

On 1 May 2013, at 00:13, Donald Stufft  wrote:

> 
> On Apr 30, 2013, at 7:10 PM, Andrew Ingram  wrote:
> 
>> On 30 Apr 2013, at 23:38, Shai Berger  wrote:
>>> I see one issue with this: According to current procedures, if this 
>>> timeline 
>>> is followed, support for 1.4 will be dropped less than 6 months after the 
>>> release of 1.5. At least for some of us (which, as I mentioned earlier on 
>>> the 
>>> list, only moved to 1.4 when the 1.5 release forced us to), this may be a 
>>> bit 
>>> of a problem.
>>> 
>>> Shai.
>> 
>> It seems like 1.4 support might need to be extended. I'm assuming that given 
>> the success of the kickstarter campaign, Andrew's schema migration 
>> functionality will be made available to 1.4, and the functionality seems to 
>> be a prerequisite for migrating to the new way of handling user models.
>> 
>> Andy
> 
> There is no requirement to migrate for the new way to handle user models. The 
> only time you'd need to migrate is if you want to swap out your existing user 
> models that Django provides with new ones. If you don't do that then you 
> don't need to migrate.

Absolutely, there's no requirement to migrate, but it does have the feel of an 
weird kind of deprecation. Obviously there are workarounds, like you said, I 
can upgrade to 1.5 without changing user models (though that does involve 
incurring a bit of technical debt). Anyway, this whole line of reasoning was 
based on the faulty belief that Andrew's work will be added to 1.4, rather than 
as an external tool, so never mind!

Andy

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

Re: Django 1.6 release timeline

[Andrew Ingram]

On 1 May 2013, at 00:35, Carl Meyer  wrote:

> On 04/30/2013 05:27 PM, Andrew Ingram wrote:
>> Absolutely, there's no requirement to migrate, but it does have the
>> feel of an weird kind of deprecation. Obviously there are
>> workarounds, like you said, I can upgrade to 1.5 without changing
>> user models (though that does involve incurring a bit of technical
>> debt).
> 
> I think it's worth being extra-clear about this to avoid scaring people
> off of 1.5 upgrades with FUD: there is no deprecation of the built-in
> User model in 1.5, and I doubt that there will be in any upcoming Django
> version. Neither is there any technical debt incurred by upgrading to
> 1.5 without switching to a custom User model. Custom user models are a
> 100% optional feature; continuing to use the built-in User model in 1.5
> is not a "workaround" for anything, it's fully supported and reasonable.
> If you already have working 1.4 code with the existing User model
> there's little reason you'd want to switch over when upgrading to 1.5
> (unless you are also adding new User-related features to your codebase).
> 
> Carl


Don't worry, I'm not misunderstanding you.

Andy

(Pointless aside: My use of technical debt comes from the idea that pre-1.5 I 
had a lot of technical debt from hacking user models that couldn't be repaid, 
so in essence it was written off. Then 1.5 suddenly made it possible to repay 
it. In general, whenever a new preferred idiom comes along, I consider legacy 
code to have gained technical debt.)

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

Re: reconsider re-opening ticket 901

[Andrew Ingram]

On 12 May 2013, at 00:55, Russell Keith-Magee  wrote:
> I'm sure I understand this argument. Python objects are passed around by 
> reference, not by value, so if you've passed in a Django object deep into 
> another library, that library will be pointing at the same instance. If the 
> instance is changed, everywhere holding a handle to that reference will be 
> updated.
> 
> To that end - I want to make sure that we're clear about what we're talking 
> about here. 
> 
> What is on the table is essentially adding a refresh() call on an object 
> instance that is an API analog of ".get(id=self.id)" (although the 
> implementation will need to do a bit more than that).
> 
> We are *not* talking about ticket #17, object instance caching. Calling 
> refresh() *will not* update *every* instance of a given object. The following 
> would be the effective API:
> 
> >>> a = MyObj.objects.get(id=42)
> >>> a.message = 'hello'
> >>> a.save()
> >>> b = MyObj.objects.get(id=42)
> >>> c = MyObj.objects.get(id=42)
> 
> >>> a.message = 'goodbye'
> >>> a.save()
> >>> print b.message
> 'hello'
> >>> b.refresh()
> >>> print b.message
> 'goodbye'
> >>> print c.message
> 'hello'

I was under the impression that the suggested use case was more like this:

>>> a = MyObj.objects.get(id=42)
>>> a.message = 'hello'
>>> b = {'obj': a}
>>> print b['obj'].message
'hello'
>>> c = MyObj.objects.get(id=42)
>>> c.message = 'goodbye'
>>> c.save()
>>> a = MyObj.objects.get(id=42)  # existing 'workaround', gives us a new 
>>> instance
>>> print a.message
'goodbye'
>>> print b['obj'].message  # b['obj'] still points to the original instance `a`
'hello'

If a reload() method existed, `a` could have been reloaded with `a.reload()`, 
and then `b['obj']` would have been up-to-date as well. As it stands, every 
reference to `a` has to be explicitly re-fetched from the database.

Am I missing something obvious?


- Andy

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

Re: Delivering PR 3114 - The _meta refactor

[Andrew Ingram]

Hi all,

Just to add a data point regarding virtual fields.

We're using them in production in our open source media library (
https://github.com/onefinestay/django-mediacat/blob/master/mediacat/fields.py#L97-L119).
Essentially, due to a number of issues, it wasn't practical to have
references to image crops to be foreign keys. Instead we have an
association table with object_content_type, object_id, crop_id and
field_name. The virtual field allows us to have an API that looks very much
like a foreign key, but behind-the-scenes does all the magic to give us the
benefits we were looking for. In the previous link, you'll also be able to
see the hack I used to get the custom field working properly in modelforms.

We're also using them a lot in other projects to seamless bridging between
database-backed models and other types, ie whenever we want something that
looks like a database column as far as the model is concerned, but isn't
one in reality.

Regards,
Andrew Ingram


On 22 December 2014 at 14:50, Collin Anderson  wrote:

> Ditto. I'm ok with a tiny shim for GFK, and we should get the API right
> for RelatedObject going forward, (as long as it's at least _possible_ to
> detect which is which and write code that works on both 1.7 and 1.8).
>
> On Monday, December 22, 2014 9:29:15 AM UTC-5, Aymeric Augustin wrote:
>>
>> Hi Russell,
>>
>> 2014-12-22 8:39 GMT+01:00 Russell Keith-Magee :
>>
>>> The question: Do we -
>>>
>>> 1) Accept this particular internal specific naming of GFK as a quirk
>>> reflecting the limitations of contrib.admin
>>>
>>> 2) Try to nail down what a "virtual" field means, or find some
>>> alternative flag to identify what "GFK" is a proxy for in this case.
>>>
>>
>> I'm in favour of (1) mostly because of the YAGNI principle. Defining
>> "virtual"  without a concrete use case sounds hard.
>>
>>
>> The question: Do we:
>>>
>>> 1) Accept this as a backwards incompatible change.
>>>
>>> 2) Accept the inconsistency in the new API.
>>>
>>> 3) Find a pair of names other than model/related_model to represent the
>>> "subject/object" pair in fields
>>>
>>
>> I'm also in favour of (1) because the point of a refactoring is to clean
>> up inconsistencies. We can say something in the release notes to help
>> people who have used the RelatedObject private API.
>>
>>
>> Best,
>>
>> --
>> Aymeric.
>>
>  --
> 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/13baaf10-2395-47f6-8d1a-3a3b1543b7ff%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/13baaf10-2395-47f6-8d1a-3a3b1543b7ff%40googlegroups.com?utm_medium=email&utm_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 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/CAOA51CU4gZRSbjL56_oD2ZGNEXq9%2BriVZ%3DT9EWbdzRqqSKsykg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: automated import sorting and better pull request checks

[Andrew Ingram]

For what it's worth, I prefer one import per line, if only because it makes
diffs that involve changes to imports a lot easier to digest, and usually
smaller.

ie, something like this:
https://gist.github.com/AndrewIngram/16da35699bd495f79adb


Andy


On 30 January 2015 at 09:36, aRkadeFR  wrote:

>  I support the idea of introducing isort.
>
> Didn't know isort before and give it a try on personal project.
> It considers only the global import of the file (I mean on the
> very top on my files and not in the methods / functions). Which
> is exactly what it should do from my point of view.
>
>
> On 01/29/2015 02:18 PM, Tim Graham wrote:
>
> As a code reviewer, I've really appreciated that we've cleaned up the code
> using flake8 and have automated "enforcement" via the CI server. I'd like
> to extend the idea to apply to standardizing import ordering using isort
> [1]. This mail is to advise everyone of the change and to address any
> concerns.
>
> Documentation:
> https://github.com/django/django/pull/4008
>
> Automated cleanups:
> https://github.com/django/django/pull/4009
>
> On a related note, the UI for flake8 errors isn't currently very good (you
> have to look at the bottom of the Jenkins build logs). I'd like to improve
> that by using a separate service that uses the GitHub status API [2] so
> that the check can run separately from the tests build. I don't want to
> reinvent the wheel though, so if there is an existing service we can use
> for this, great. I'd like to also add checks for documentation build and
> spelling errors, as well as isort checks (assuming adoption per above).
>
> [1] https://github.com/timothycrosley/isort#readme
> [2]
> https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
>  --
> 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/d356e388-fa45-4fdf-871f-ce484a7b43bf%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 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/54CB5092.90507%40arkade.info
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Feature: Support a javascript template language on the server

[Andrew Ingram]

Based on my own experiences building isomorphic JavaScript apps with
Django, I haven't had any issues where I felt Django was getting in my way.
I've tackled the problem in two different ways, both of which worked
without any great difficulty:

1. The primary web-app is actually a node process. Everything you'd
consider a view is handled by React and React-Router, data requirements are
handled by making an HTTP request to Django REST Framework. This isn't
especially efficient, since the base response times aren't great when
you're depending on HTTP for data (this can obviously be improved by
getting the data via other channels).
2. Use node purely as a rendering engine. I actually created an alternative
to TemplateResponseMixin that communicated with a node process via zerorpc
(chosen for the sake of simplicity) rather than rendering a template from
disk. This abstraction could be made neater by packaging it up as a custom
template engine that takes care of converting the data into a format that
zerorpc accepts (ie no querysets or rich objects). This approach was
significantly faster with base response times of about 8ms for a simple
page with no data dependencies, but I felt I was implementing my routing
logic twice (once in Django, once in node).

The second approach is easier to get running at acceptable performance
levels quickly, but is quite clunky to implement. Going forward I'm
probably going to favour the first approach, which essentially means
turning my Django projects into nothing more than a data layer, which is
fine for me because I've found that once you're using React (or similar)
heavily, you're not using much else from Django anyway.

Andy



On 2 June 2015 at 07:43, Emil Stenström  wrote:

> On Tuesday, 2 June 2015 05:19:43 UTC+2, Bobby Mozumder wrote:
>>
>> At this point it’s probably easiest for Django to provide templates only
>> for Javascript front-end, and for Django to only serve API endpoints.
>>
>> We really don’t need Django to serve HTML pages anymore, except for the
>> initial page-load.
>>
>
> In 2012, Twitter posted in their engineering blog about their conclusions
> of trying to move all rendering to the client. It was just too slow. The
> answer, and what is considered "best practice" now, is to render everything
> on the server the first load, and render all subsequent page loads to the
> client. This also means you get a nice fallback for clients that don't
> support javascript.
>
> --
> 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/783577b2-79f4-4445-81de-3208a16037a4%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 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/CAOA51CX1Or0XDbtpEpN%2BZmwE3ExDG5c5nihfwR0vnWG4_CkLQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support a javascript template language on the server

[Andrew Ingram]

I feel we're getting a bit derailed here, but it seems I didn't explain
what I was doing well enough.

I'm saying that in both approaches I've used, I was authoring an isomorphic
React application - i.e. returning a fully-rendered html document with all
the React checksum IDs pre-populated. In my first approach I had a very
thin express server in node that passed request parameters to React Router,
which ultimately returned a rendered page. In my second approach, I had
Django hand over template context and request parameters to the node
process, which also returned the fully-rendered document. I picked the
second approach because it performed better to start with, but I prefer the
first approach in terms of how clean the stack is.

I'm a big fan of all the front-end work Facebook is putting out, I'm a
total convert, it's basically solved almost everything that's annoyed me
about web dev for the last 10 years. But Django has an excellent data
layer, and I want to keep using it if I can.

Andy



On 2 June 2015 at 18:17, Emil Stenström  wrote:

> On Tuesday, 2 June 2015 12:58:22 UTC+2, Andrew Ingram wrote:
>>
>> Based on my own experiences building isomorphic JavaScript apps with
>> Django, I haven't had any issues where I felt Django was getting in my way.
>> I've tackled the problem in two different ways, both of which worked
>> without any great difficulty:
>>
>
> I think the reason that Django has not been in the way here is that you
> have pushed it out of the way, and just reimplemented features that Django
> should have in javascript instead. I'm not saying this is bad for your
> project, it's just a shame that it's not something that Django can handle.
> More concretely:
>
> 1. The primary web-app is actually a node process. Everything you'd
>> consider a view is handled by React and React-Router, data requirements are
>> handled by making an HTTP request to Django REST Framework. This isn't
>> especially efficient, since the base response times aren't great when
>> you're depending on HTTP for data (this can obviously be improved by
>> getting the data via other channels).
>>
>
> Here you use routing and views from React instead of using Django. The
> problem with this is as you say latency since getting data is a HTTP
> request, but you also get slow initial load times since there's no content
> to show. Rendering on the server first to get a quick initial load, and
> then delegating to React would give us the best of both worlds.
>
>
>> 2. Use node purely as a rendering engine. I actually created an
>> alternative to TemplateResponseMixin that communicated with a node process
>> via zerorpc (chosen for the sake of simplicity) rather than rendering a
>> template from disk. This abstraction could be made neater by packaging it
>> up as a custom template engine that takes care of converting the data into
>> a format that zerorpc accepts (ie no querysets or rich objects). This
>> approach was significantly faster with base response times of about 8ms for
>> a simple page with no data dependencies, but I felt I was implementing my
>> routing logic twice (once in Django, once in node).
>>
>
> This sounds excellent. It's almost like implementing a new template
> engine, but instead just running it through node. The downside is that it
> requires you to install, deploy and maintain a separate javascript
> environment. What js template language were you using?
>
> I think implementing that same language for Django would give you the best
> of two worlds. All server-side rendering would remain like for any
> server-side app, but you could also send your templates to the view for
> fast client side rendering.
>
>
>> The second approach is easier to get running at acceptable performance
>> levels quickly, but is quite clunky to implement. Going forward I'm
>> probably going to favour the first approach, which essentially means
>> turning my Django projects into nothing more than a data layer, which is
>> fine for me because I've found that once you're using React (or similar)
>> heavily, you're not using much else from Django anyway.
>>
>
> Did you read the Twitter post on this (
> https://blog.twitter.com/2012/improving-performance-on-twittercom)? They
> went the same route, moving all template logic to the client, found it was
> too slow on initial load, and then favoured the dual approach I'm hoping
> for.
>
> --
> 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

Re: Django support added to BuiltWith!

[Andrew Ingram]

On 20 Dec 2010, at 06:40, Russell Keith-Magee wrote:
> 
> No, there aren't any completely reliable clues -- and in my opinion,
> that's a good thing.
> 
> Providing an easy way to identify a Django site serves no purpose
> other than inflating project ego. On the other hand, if I am a black
> hat hacker, and i want to take down your site, being able to easily
> identify the software running your site dramatically narrows the
> search for possible attack vectors.
> 
> As much as I enjoy the trainspotting aspect of knowing where Django is
> being used, it is information that doesn't need to be shared by
> default. If I want to share the technology that I have used in
> building my site, I can put up a colophon page, or write a case study
> on a blog, or any number of other options. I see no reason that this
> information needs to be machine readable at all, let alone machine
> readable by default.
> 
> As Jeremy has noted, the closest you will get to easily identifying a
> Django site is to look for the telltale signs of the admin site, but
> admin is not universally deployed, nor is it universally deployed at
> /admin (in fact, I routinely use a different URL for admin
> deployment). You might also get some hints out of session cookie
> naming - but again, not every site uses Django's session framework,
> and if they do, the session cookie name is configurable.
> 
> Yours,
> Russ Magee %-)

I agree, if you can tell what server-side tools are in use then someone has 
probably done something wrong somewhere.

You may be able to guess what framework is in use by spotting certain design 
patterns that are pushed particularly strongly by a framework, but as all 
frameworks gradually move towards best practices  it'll become increasingly 
difficult to tell them apart. This is definitely a good thing, I am generally 
rather pleased if I can deploy something without someone knowing what server 
side tools are in use.

- Andrew Ingram

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

MultipleObjectMixin and Pagination

[Andrew Ingram]

Hi All,

I've been working with Django's class-based views a fair bit recently,
specifically to create some additional ones (dealing with formsets
mostly). I've been trying to inherit as much of the existing
functionality as possible, but I've hit a bit of a snag.

I've a ModelFormSetMixin which extends MultipleObjectMixin, much like
how ModelFormMixin extends SingleObjectMixin in core.

I want to take advantage of the pagination that MultipleObjectMixin
provides, but I need it at the point of instantiating the FormSet.
Currently MultipleObjectMixin does all the pagination handling in
get_context_data which means I have to either re-implement a lot more
functionality than I'd like, or execute the pagination calculation
twice.

My ideal solution would be for MultipleObjectMixin to be changed to
have the pagination handled as early as possible so that I can take
advantage of it for free.

This is only one use case, but I'm sure there are more. I'm happy to
try and come up with a patch if there's some agreement on this.

The FormSet views I've developed can be seen here:
https://github.com/AndrewIngram/django-extra-views/blob/master/extra_views/formsets.py


Regards,
Andrew Ingram

-- 
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: MultipleObjectMixin and Pagination

[Andrew Ingram]

Hi Julien,

I'm already involved on that ticket, the pagination issue is part of what's 
holding me back from contributing a patch. So I was looking to get some 
discussion about whether it's something that needs to be solved in core. In 
light of what you've said, I'm trying to think of a more straightforward 
test case that isn't tied to my ModelFormSetView.

- Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/0-7LrGdIEo8J.
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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

[Andrew Ingram]

On 9 Jul 2011, at 10:44, Sam Lai wrote:

> I concur. The consensus seems to be shifting towards a 'strip' flag
> though (defaulting to false), and I'm +1 on that. That would make it
> explicit, minimise repetitive boilerplate code and also make it less
> likely to accidentally forget to strip a field somewhere in the
> process.
> 
> Maybe a revisit to this related ticket is in order?
> https://code.djangoproject.com/ticket/4960

I'm on the fence here, I like the idea of a strip flag, but I do agree that it 
seems too specific. Perhaps something more generic, eg:

myfield = models.CharField(max_length=255, text_filters=[StripFilter, 
UpperFilter])

The filters would chain into each other. I'm not sure I like the syntax though, 
seems a bit ugly. I do like the elegance of just having a strip flag.

- Andy

-- 
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: Splitting out admin functionality

[Andrew Ingram]

On 10 October 2011 13:13, Russell Keith-Magee wrote:
>
> The approach taken by django-messages should be the model here. When a
> new messages framework was proposed for Django in 1.2, an effort was
> made to find out all the features that were desirable, and then pull
> together all those features into a third party library that borrowed
> code from all the available implementations. The same approach should
> be taken here -- find out all the features that we want to have in
> generic views (e.g., formsets, fieldsets, filtering, ordering, table
> rendering), build an amalgam library that takes the best parts from
> all the available 3rd party libraries, and develop that into a single
> patch that can be applied to trunk.
>

On this point, I'd like to draw attention to my own set of class-based views
which provide formsets functionality, mimicking the APIs of the existing
CBVs as closely as possible. The ultimate goal was to attempt to reimplement
some of Django's admin as a proof-of-concept. It doesn't support any
higher-level functionality like fieldsets, filtering and sorting, and
there's an issue with pagination (see this ticket:
https://code.djangoproject.com/ticket/16432), but it's fairly
feature-complete and could be a good starting point.

- Andrew

-- 
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: Custom prefetches (#17001)

[Andrew Ingram]

I'd love to see this solved. I'm not sold on the API, but then again I've
yet to see a single suggested API for this problem that I actually like.

I showed you this a little while ago, you had some reservations with my
idea, but I figured I might as well add it to the conversation anyway:
https://gist.github.com/AndrewIngram/5636041

Essentially, I'm wondering if extending the prefetch_related concept is the
right approach, and whether it's instead worth exploring the more general
idea of "attaching stuff to models at the ORM level". There're a lot of
useful concepts from other ORMs related to attaching prebuilt data
structures like arrays, dicts, calculated values, filtered annotations, etc
to models. The problems all seem somewhat related, and I'm worried about
the possibility of solving them all in completely different ways.

Regards,
Andy



On 23 August 2013 16:03, Marc Tamlyn  wrote:

> Ticket #17001 concerns the ability to customise the querysets used when
> using `prefetch_related()`. This has a working implementation with a less
> than ideal API - see the patches on the ticket.
>
> As the API design seems to be the main issue here, Anssi and I bounced
> some ideas around on IRC, and I thought it best to propose our best
> approach here to gather opinions on whether the API is palatable.
>
> Firstly note that the existing API would continue to work as it does now:
> Publisher.objects.prefetch_related('authors', 'authors__books')
> You can then access publisher.authors.all() as before, each of which will
> allow you to access author.books.all()
>
> If you wanted to prefetch the authors ordered by their age rather than
> whatever the default is, you can do:
> Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
> queryset=Author.objects.order_by('age'))
> The authors are now available as publisher.authors_by_age - this is a list
> (not a qs) of the relevant Author objects.
>
> Only one custom field can be prefetched at once in this way. So if you
> wanted to get the books prefetched as well, you would need to do:
> Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
> queryset=Author.objects.order_by('age').prefetch_related('books'))
>
> An alternative API that may work for this case is:
> Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
> queryset=Author.objects.order_by('age')).prefetch_related('authors_by_age__books')
> i.e. the custom prefetch can be referenced in future chained prefetch
> calls.
>
> This API can be used to customise the second level only:
> Publisher.objects.prefetch_related('authors').prefetch_related('authors__books',
> to_attr='unpublished_books', queryset=Book.objects.filter(published=False))
>
> If you want to customise both levels though, you must use the first
> approach:
> author_qs = Author.objects.order_by('age').prefetch_related('books',
> to_attr='unpublished_books', queryset=Book.objects.filter(published=False))
> Publisher.objects.prefetch_related('authors', to_attr='authors_by_age',
> queryset=author_qs)
>
>
> Opinions are welcome!
>
> Marc
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Custom prefetches (#17001)

[Andrew Ingram]

Yeah, that was Marc's main issue with the idea too. Based on that
distinction it makes sense to keep the two as separate concepts, but as far
as API design is concerned it makes sense to try and make them feel similar.


On 23 August 2013 18:25, Anssi Kääriäinen  wrote:

> On Friday, August 23, 2013 6:25:42 PM UTC+3, Andrew Ingram wrote:
>>
>> I'd love to see this solved. I'm not sold on the API, but then again I've
>> yet to see a single suggested API for this problem that I actually like.
>>
>> I showed you this a little while ago, you had some reservations with my
>> idea, but I figured I might as well add it to the conversation anyway:
>> https://gist.github.**com/AndrewIngram/5636041<https://gist.github.com/AndrewIngram/5636041>
>>
>> Essentially, I'm wondering if extending the prefetch_related concept is
>> the right approach, and whether it's instead worth exploring the more
>> general idea of "attaching stuff to models at the ORM level". There're a
>> lot of useful concepts from other ORMs related to attaching prebuilt data
>> structures like arrays, dicts, calculated values, filtered annotations, etc
>> to models. The problems all seem somewhat related, and I'm worried about
>> the possibility of solving them all in completely different ways.
>>
>
> I don't like the idea of mixing annotate() and prefetch_related().
> Annotations work inside the query, prefetch_related runs additional queries.
>
> That being said I do like the idea of
> .annotate(active_authors=Count('authors').filter(active=True)). There is an
> old ticket about this sort of annotation, see
> https://code.djangoproject.com/ticket/11305.
>
>  - Anssi
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: FormSetView and ModelFormSetView

[Andrew Ingram]

Having basically built all of the views in question, I agree with Russell.
By having multiple form classes in a view itself, you're essentially
pulling validation logic out of the form and into the view where it doesn't
belong. A view shouldn't be concerned with the specifics of validation, it
should be concerned with what to do once you have the validated data.

For example: I have a Form and a FormSet, I have a field on the form that
is only required if the formset has zero rows. Conventional solutions
involving having the form and formset on the view are all pretty ugly.
Whereas if the form itself knows how to validated any "subforms", you get
much better options.

I'm not entirely sold on the concept of FormContainer, i'd learn more
towards new fields like `forms.SubForm(MyForm)` or
`forms.SubFormSet(MyFormSet)` (assuming such a thing is achievable). Then
we get a nice a familiar API, and are able to do things on the parent form
such as being able to define a clean_* method for subforms/sets.


Andy


On 20 September 2013 07:55, Russell Keith-Magee wrote:

>
> On Fri, Sep 20, 2013 at 2:41 PM, Marc Tamlyn wrote:
>
>> This is partly because there's no obvious correct implementation of them
>> ;)
>>
>> Yes, I think these views should exist. But they go with the same body of
>> work as handling multiple forms, inline formsets etc. At present I have no
>> yet found the time to think about this problem, as a whole and come up with
>> a single consistent solution.
>>
> I'm not sure FormSetView *should* exist. I'd be a lot more inclined to
> look at something like FormContainer -- a form-like container that can
> contain multiple forms and formsets. There's a sample implementation on
> #18830 in the context of extending FormWizard to support combinations of
> form and formset.
>
> https://code.djangoproject.com/ticket/18830
>
> If you had a form container, you wouldn't need a new generic view -- you
> can just use FormView, and use the FormContainer as the form.
>
> (I'd also like to rethink generics in general, but that's a whole other
> conversation… and one that I need to internally progress from vauge
> rambling to slightly coherent proposal… and then find time to work on :-)
>
> Yours,
> Russ Magee %-)
>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Vendoring Select2

[Andrew Ingram]

In previous projects (before moving to rolling my own UI components), I
ended up favouring Selectize (http://selectize.github.io/selectize.js/)
after getting fed up with Chosen and Select2 - but this was a few years ago
and I can't remember my reasons. But if it hasn't been considered, it might
be worth a look.

Andy

On 6 April 2016 at 15:20, Marc Tamlyn  wrote:

> Agreed. I recently was trying to use a fitler horizontal widget on my
> phone and thought the whole thing was broken because ` multiple=mutliple>` looks so wrong. I'd love to see this experience
> improved, and select2 is a good reliable solution.
>
> On 6 April 2016 at 15:11, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> I’m OK with this. It's a reasonable solution.
>>
>> --
>> Aymeric.
>>
>> On 06 Apr 2016, at 15:25, Johannes Hoppe  wrote:
>>
>> Hi,
>>
>> as promised I started working on an autocomplete field for
>> `django.contrib.admin` as a more convenient alternative to `row_id_fields`.
>>
>> We had a longer discussion in the ticket and also at the sprints at
>> DjangoConEU with some of the maintainers for famous 3rd party autocomplete
>> integrations.
>>
>> We concluded that select2 is the most mature and stable solution, that
>> also doesn't require us to write our own JS code. (I know how much we hate
>> it ;)
>>
>> Notable:
>> 1. In order to use `jQuery.noConflict(true);` I hat to add a wrapper
>> around the vendored Select2 library. I think that is better than leaving
>> `jQuery` in the global namespace.
>> 2. `$.select2` will only be added to `django.jQuery` and therefore not
>> interfere with other implementations. One should still be able to use 3rd
>> party libraries.
>> 3. Select2 is unter MIT license.
>>
>> All in all I tried not to break anything and have this as new opt in
>> solution. Lets see how it plays out.
>>
>> All I need for you is to decided on wether or not with should vendor
>> Select2.
>>
>> PR is here: https://github.com/django/django/pull/6385
>>
>> Thanks in advance!
>> Joe
>>
>> --
>> 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/21cbed67-1ecb-4e04-a8d6-746cb363beab%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 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%40polytechnique.org
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1EkkH9SGG-Pss2JQTj0%3DJ8dRYnF3_Stt1hbqZrYqGYh0g%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOA51CW

Re: Deprecate is_superuser, is_staff and is_active

[Andrew Ingram]

I've always felt that `is_staff` should be changed to a permission such as
`can_access_admin` provided by the Admin app itself. However,
`is_superuser` is slightly different, in that it's not a permission, but
rather a flag that says "this user has EVERY permission". It's also
potentially nonsensical from a functional perspective, you could have two
permissions that are intended to be mutually exclusive, but a superuser
would nonetheless have both of them - potentially resulting in a
broken/nonsense UI. This is the main reason why almost nobody should be a
superuser (yet nearly every Django project i've inherited has nearly every
member of staff marked as superusers).

`is_active` is intended to be used a little differently isn't it? It's not
saying "user has no permissions", it's saying "user is disabled". It's not
access-control, it's data.

I think that most of it could do with a rethink, but `is_staff` is probably
the biggest wart.

Andy

On Fri, 24 Mar 2017 at 11:31 guettli 
wrote:

> I know this is a crazy idea, and it will get the "won't fix" tag very soon.
>
> Nevertheless I want to speak it out.
>
> My use case: Get a queryset of users who have a given permission.
>
> I would like to get this with a simple SQL statement.
>
> At the moment this query is complex and results in performance issues,
> since
> several outer joins get created. See:
> https://groups.google.com/forum/#!topic/django-users/lUGkZybXllM
>
> is_superuser and is_staff could be changed to permissions easily.
>
> It's different with is_active. But again: a simple SQL to get all users
> which have a given permission is my goal.
>
> I personally could live without is_active: Just remove all permissions for
> this user.
>
> If you don't like dropping all perms to make a user inactive since you
> want to switch back and forward between active and inactive   ...
> then this a different (bigger) problem: switching back and forward between
> states. Why not solve
> this for all models (not just User instances)? But this is a different
> topic :-)
>
> I know the road to deprecate these three friends would be hard since a lot
> of code uses them.
>
> What do you think?
>
>
>
>
>
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/961fd91c-3954-4c7f-a05e-807f2863dc5e%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 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOA51CV4KTQHREgQ046nCF2You7kZB407c3jKjgn%3D-%2B0ObREvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.