Changing the AdminSite instance (and class) to use BEFORE the autodiscover runs

2016-01-22 Thread Luis Masuelli
I would like to create a custom AdminSite instance, using a custom subclass of my own, and provide some project-level urls for the AdminSite. However, I would like to still benefit from the autodiscover feature. Is there a way I can instance a custom AdminSite subclass, and have that instance r

Re: Admin is still annoying regarding model save(), and model post_save signals.

2016-01-12 Thread Luis Masuelli
Notes: This is only annoying when the logic involves many2many fields. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com.

Admin is still annoying regarding model save(), and model post_save signals.

2016-01-12 Thread Luis Masuelli
If you want to perform additional logic when you save your model... class MyModel(models.Model): #... def save(self, *args, **kwargs): self.a_rel_model_set.add(O) super(MyModel, self).save(*args, **kwargs) self.another_rel_model_set.add(O2) Or similar login in

What will be the replacement for .extra()?

2015-12-09 Thread Luis Masuelli
When I see the docs (https://docs.djangoproject.com/en/1.8/ref/models/querysets/#extra), I notice .extra will be deprecated and removed. Is there a plan for the replacement? As I see it, limiting ourselves to using Manager.raw() is not a good idea, since you cannot work anymore on a RawQueryset

Internationalization to 3rd party Django apps

2015-03-26 Thread Luis Masuelli
I use django-rest-framework==3.0 in an application as an example case (*) of what I am talking about. Most of the messages in DRF are not internationalized, and had to use the following mechanism to create the internationalization for DRF messages: - Properly set LANGUAGES and locale directo

Re: Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

2015-02-27 Thread Luis Masuelli
Thanks :D Did not think about squashing migrations as solution for this problem! But it does the job. OTOH the fact about historical models has nothing to do with my problem (since it is not related at all with instancing a model, but just about the definition and not getting a NameError). --

Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

2015-02-25 Thread Luis Masuelli
I have an issue with migrations. Suppose I declare (in my application, with name myapp) a field with a validators= declared. In such value (which is an iterable), I declare a function: class MyModel(models.Model): """ This one is identifiable. """ identifier = models.CharField(