Re: RFC: Query Methods

[Aaron Merriam]

Tai, we use that same structure at my work and so far it has worked well.

https://github.com/fusionbox/django-fusionbox/blob/master/fusionbox/db/models.py

It also extends well.  You can define queryset methods elsewhere and then 
inherit from them on multiple models to reuse those methods easily.  So far 
it has been a really nice solution for us.

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

Status of ticket #14087 - management commands in namespace packages

[Aaron Merriam]

I'm curious if someone can shed some light on ticket #14087 
(https://code.djangoproject.com/ticket/14087)

It appears there is a pull request open on github to fix this issue 
(https://github.com/django/django/pull/178)

This recently became a problem when we separated out a few apps into 
individual packages under the same namespace and there doesn't appear to be 
any sane way to monkeypatch around the issue.

-- 
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/-/6RBbrue81eMJ.
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: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

[Aaron Merriam]

Just wanted to put my +1 into this thread.  I've been fighting for a clean 
way to implement permissions in class based views and the 'init' method 
would help my implementation be a lot more DRY.

On Wednesday, October 31, 2012 12:42:33 PM UTC-6, Jordan Hagan wrote:
>
> Diedreik,
>
> Thanks for your comments - your solution seems similar to the one proposed 
> by Meshy unless I'm missing something (https://gist.github.com/1957251). 
> It is good to see multiple people coming up with the same solution to the 
> issue independently though as that to me is an indication that we're moving 
> in the right direction.
>
> Meshy,
>
> Thanks for the link - the django-braces project looks useful - I'll 
> probably start using that.
>
> I would love to get some input from a core developer (or two) on this to 
> see where they stand. From where I'm sitting there seems to be a number of 
> people working around this problem in more or less the same manner, and 
> most of the arguments against haven't taken into 
> consideration compatibility with other mixins, already existing class 
> methods, etc.
>
> I would be happy to put together a patch in a ticket on trac and do any 
> other grunt work required to make this happen.
>
> Cheers,
> Jordan
>
> On Wednesday, 31 October 2012 22:57:28 UTC+13, Meshy wrote:
>>
>> Marc and I have been using a mixin to override `dispatch()` with this 
>> functionality. He has an ongoing pull request on 
>> django-braceswith the code. 
>> I hope this can be useful to some of you.
>>
>> Meshy.
>>
>> On Wednesday, October 31, 2012 9:49:26 AM UTC, Diederik van der Boor 
>> wrote:
>>>
>>> Hi,
>>>
>>> Please allow me to add my €0.02.
>>> In a large project I've experienced a similar issue; and we solved it in 
>>> a slightly different way.
>>> What we also noticed was:
>>> - overriding dispatch(), get() or post() wasn't good enough anymore.
>>> - the views need some initialization moment before their workflow (in 
>>> get/post of the base classes) start.
>>>
>>> What we ended up with is this base class (simplified a bit):
>>> https://gist.github.com/3985939
>>>
>>> *I seriously propose having such init() function in the Django views.*
>>> Mind you, that took a heated debate in the organization I was contacted 
>>> for, so please allow me to explain to context here.
>>> I think we've found a missing cornerstone in the way the class based 
>>> views are structured, and there is an easy fix.
>>>
>>> *What is the problem with overriding dispatch()?*
>>> When overriding dispatch(), get() or post() the flow is always:
>>>
>>> def dispatch(self, request, *args, **kwargs):
>>> # my code here.
>>> return super(…).dispatch(request, *args, **kwargs)
>>>
>>> The same also applies to get() and post().
>>> In other words, the last deriving class on top of the inheritance chain 
>>> is always initializing first before it's base classes.
>>> It can't rely on a base class to do some initialization.
>>>
>>> With our permission check in the base class' dispatch() method, anything 
>>> deriving from that effectively
>>> couldn't override dispatch() anymore because that would run before the 
>>> permission check.
>>>
>>> *How does the init method fix this?*
>>> By doing a self.init() in the top-most dispatch() method, each class in 
>>> the inheritance chain has a chance to fetch the objects it needs to have.
>>>
>>> That code can be written as:
>>>
>>> def init(self):
>>> super(..).init()
>>> # my code here.
>>>
>>> Now, the base class can initialize, then the deriving class.
>>> With a larger inheritance chain, this behavior becomes crucial.
>>> Each class can build upon what the other has prepared already.
>>>
>>>
>>> All of a sudden, we could do things like this:
>>>
>>> class PhotoListView(TabbedListView):
>>> """
>>> Contents of an photo album; a list of photo's.
>>> """
>>> model = Photo
>>>
>>> template_name = "photoalbum_album.html"
>>> permission_class = permissions.PhotoAlbumViewPermission
>>>
>>> def init(self):
>>> super(PhotoListView, self).init()
>>> self.photoalbum = get_object_or_404(PhotoAlbum, 
>>> pk=self.kwargs['pk'])  # parent object that filters the list
>>>
>>> def get_queryset(self):
>>> return super(PhotoListView, 
>>> self).get_queryset().in_album(self.photoalbum)
>>>
>>> def get_context_data(self, **kwargs):
>>> context = super(PhotoListView, self).get_context_data(**kwargs)
>>> context['photoalbum'] = self.photoalbum
>>> context['can_delete'] = self.is_authorized_for(PhotoDeleteView)
>>> return context
>>>
>>> This is a list view for photo's, and it's limited to a current photo 
>>> album.
>>> The alternative is making a DetailView, and putting the photo's 
>>> somewhere in get_context_data() and thereby loose what the list view 
>>> has to offer.
>>> Now we can just state it's a list view (which it is), and introduce the 
>>> filt

Re: Class based views: A standard hook for http-method-independent code

[Aaron Merriam]

I wanted to post and modified version of a gist posted earlier in this 
thread.

https://gist.github.com/4032482

I originally implemented the original structure of having an `init` hook 
which was called between setting request, args, and kwargs, but i quickly 
found that I had a few situations where I needed to fully hijack the 
response rather than just checking a permission or throwing an exception.  

I'm curious what others think of this.

On Thursday, March 1, 2012 11:38:08 AM UTC-7, Marc Tamlyn wrote:
>
> Hi all,
>
> Apologies if this has been raised before. I've had a look around and can't 
> find a good way of doing this with the current code.
>
> I regularly have views which rely on some custom code which runs some 
> sanity checking on the request and is independent of method. As an example, 
> consider a view which creates an object related to a parent. This is easily 
> achievable by overriding the form_valid method of CreateView and excluding 
> the foreign key from the form. However, the view should return a 404 if the 
> related object specified by the url does not exist. Written as a non class 
> based view, the natural flow is to try to load the parent object from the 
> database, handle it as necessary, and then split paths depending on whether 
> we have a get or post. It is currently very difficult to emulate this 
> without duplication of some sort.
>
> My proposal is that we add a process_request (or similar name) method 
> which is called by the dispatch method immediately before the method 
> handler is called. (i.e. 
> here).
>  
> This would then allow pre-processing and sanity checking of the request 
> object, using the args, kwargs and request that have been saved on the 
> class, before delegating off the the respective views. The method should 
> return None or an HttpResponse subclass. If it returns something, then we 
> return that directly from the dispatch method.
>
>
> I can supply some code (my proposal is pretty simple I think) but I 
> thought I'd open it up for discussion first.
>
> Marc Tamlyn
>

-- 
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/-/AIp8gnyrAuYJ.
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: Class based views: A standard hook for http-method-independent code

[Aaron Merriam]

Without setting request, args, and kwargs on on the view instance (which is 
done during the base dispatch view), anything in the view that assumes 
these values are present cannot run.  

Most of my views end up with functions which retrieve an object and then do 
some basic validation to ensure that a user has permissions, or that the 
object is valid in some fashion, or that some set of conditions is met 
prior to allowing any method call to happen.  

I have found that without this init method, the vast majority of my views 
end up re-writing dispatch which includes the super call.  This is 
especially annoying when you have to compare some aspect of the requesting 
user with an object that must be looked up with something from args or 
kwargs.  My view often already has this machinery built in, but it can't 
function without dispatch setting request, args, and kwargs, so to 
accomplish my check, I have to duplicate the lookup code in my dispatch 
method.

I don't propose mine is the best solution, but I know that it is 
non-intrusive, simple, and covers my use cases well.  It is also simple to 
accomplish any number of things since `init` merely needs to return a falsy 
value to allow the request to pass on through, raise an exception if that 
type of failure is desired, or return a response of it wants to hijack the 
view entirely.

On Thursday, November 8, 2012 4:29:54 PM UTC-7, Russell Keith-Magee wrote:
>
>
>
> On Thu, Nov 8, 2012 at 8:42 PM, Diederik van der Boor 
> 
> > wrote:
>
>>
>> Op 7 nov. 2012, om 17:49 heeft Aaron Merriam het volgende geschreven:
>>
>> I wanted to post and modified version of a gist posted earlier in this 
>> thread.
>>
>> https://gist.github.com/4032482
>>
>> I originally implemented the original structure of having an `init` hook 
>> which was called between setting request, args, and kwargs, but i quickly 
>> found that I had a few situations where I needed to fully hijack the 
>> response rather than just checking a permission or throwing an exception.  
>>
>> I'm curious what others think of this.
>>
>>
>> I really like the idea of this implementation. I do like to see some 
>> examples associated with this feature,
>> and I think that would be valuable for everyone :)
>>
>> I still think such init() or initial() feature would be beneficial for 
>> CBV's,
>> and actually reduce complexity (cc Russell here) but the examples make 
>> the difference here :)
>>
>> For example, how would this be written without a init method?
>>
>>
>> class PhotoListView(TabbedListView):
>> """
>> Contents of an photo album; a list of photo's.
>> """
>> model = Photo
>>
>> template_name = "photoalbum_album.html"
>> permission_class = permissions.**PhotoAlbumViewPerm**ission
>>
>> def init(self):
>> super(PhotoListView, self).init()  # runs permission checks
>> self.photoalbum = get_object_or_404(PhotoAlbum, 
>> pk=self.kwargs['pk'])  # parent object that filters the list
>>
>> def get_queryset(self):
>> return super(PhotoListView, self).get_queryset().in_album(
>> self.photoalbum)
>>
>> def get_context_data(self, **kwargs):
>> context = super(PhotoListView, self).get_context_data(kwarg**
>> s)
>> context['photoalbum'] = self.photoalbum
>> context['can_delete'] = self.is_authorized_for(**PhotoDe**
>> leteView)
>> return context
>>
>>
>> Off course you can, but I'd like to initiate that challenge to get a good 
>> view of the complexity trade-offs here.
>>
>>
> I'd like to offer an answer here, but it isn't clear to me at all what 
> this is trying to do (or rather, what ordering dependencies are assumed to 
> exist.
>
> For some reason, init() is apparently doing permission checks by default 
> -- but it isn't clear what causes those permission checks to be done; it 
> also isn't clear how you can do permission checks before you've actually 
> got an object to work with. 
>
> As far as setting self.photoset -- that could be done in dispatch(), or in 
> get(), or possibly even in get_queryset(). 
>
> In short, there isn't enough detail here for me to pass comment.
>
> Yours,
> Russ Magee %-)
>

-- 
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/-/lCqS_6cthaIJ.
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: Class based views: A standard hook for http-method-independent code

[Aaron Merriam]

That pattern has nasty side-effects.  It can be used in some cases but it 
fails in most.

On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote:
>
>   I’ve done the below in the past, the only issue with that is if you 
> have side effects in parent’s dispatch you don’t want executed but you 
> would also run that risk if you had an initialize() method work flow; in 
> the end I find dispatch() is enough in my experience. 
>  
> def dispatch(self, request, *args, **kwargs):
> parent_dispatch_return = super(Class, self).dispatch(request, *args, 
> **kwargs)
> ...my code based on values based on the super call...
> return parent_dispatch_return
>   
>  *From:* Jordan Hagan  
> *Sent:* Friday, November 09, 2012 12:37 AM
> *To:* django-d...@googlegroups.com  
> *Subject:* Re: Class based views: A standard hook for 
> http-method-independent code
>  
> Hey Russ, 
>  
> The main point of concern which I think you may be missing is that 
> self.kwargs and self.args are set inside dispatch, so using other mixins 
> that require self.kwargs and self.args to be set (most do) will not work, 
> without doing:
>  
> def dispatch(self, request, *args, **kwargs):
> self.args = args;
> self.kwargs = kwargs
> self.init()
> return super(Class, self).dispatch(request, *args, **kwargs)
>  
> Which isn't very tidy, to me having self.args and self.kwargs be set twice 
> (once in my overridden dispatch method, and once in the original dispatch) 
> feels wrong. I can't give you a good reason for it, it just feels bad every 
> time I do it. The only way to work around this is to override dispatch 
> without calling the original, and essentially duplicate the original 
> dispatch method with an init call added in.
>  
> Cheers,
> Jordan
>   
> On Fri, Nov 9, 2012 at 6:25 PM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>>
>>  On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam 
>> 
>> > wrote:
>>
>>> Without setting request, args, and kwargs on on the view instance (which 
>>> is done during the base dispatch view), anything in the view that assumes 
>>> these values are present cannot run.   
>>>  
>>> Most of my views end up with functions which retrieve an object and then 
>>> do some basic validation to ensure that a user has permissions, or that the 
>>> object is valid in some fashion, or that some set of conditions is met 
>>> prior to allowing any method call to happen.  
>>>  
>>> I have found that without this init method, the vast majority of my 
>>> views end up re-writing dispatch which includes the super call.  This is 
>>> especially annoying when you have to compare some aspect of the requesting 
>>> user with an object that must be looked up with something from args or 
>>> kwargs.  My view often already has this machinery built in, but it can't 
>>> function without dispatch setting request, args, and kwargs, so to 
>>> accomplish my check, I have to duplicate the lookup code in my dispatch 
>>> method.
>>>  
>>> I don't propose mine is the best solution, but I know that it is 
>>> non-intrusive, simple, and covers my use cases well.  It is also simple to 
>>> accomplish any number of things since `init` merely needs to return a falsy 
>>> value to allow the request to pass on through, raise an exception if that 
>>> type of failure is desired, or return a response of it wants to hijack the 
>>> view entirely.
>>>
>>>  
>> I'm starting to feel like I'm incredibly dense, because I still don't 
>> understand what your use case *is* - or, at least, why what your proposing 
>> provides any significant advantages over what you can do using basic Python 
>> inheritance techniques.
>>  
>> Specifically, I still can't see why:
>>  
>>  class MyView(View):
>>  def  dispatch(self, request, *args, **kwargs):
>> init()
>> return super(MyView, self).dispatch(request, *args, **kwargs)
>>  
>> def init():
>> # your init logic here
>>  
>> is superior to the solution provided by using basic Python inheritance:
>>  
>> class MyView(View):
>>  def  dispatch(self, request, *args, **kwargs):
>> # your init logic here
>> return super(MyView, self).dispatch(request, *args, **kwargs)
>>  
>>  You have exactly the same workflow, and exactly the same order of 
>> operations. You don't need to document any special CBV-specific API -- 
>&g

Re: Class based views: A standard hook for http-method-independent code

[Aaron Merriam]

If the super call changes any data then by the time you've run whatever 
code comes after the super call, the changes have already occured.  


   - If you wait to call super before running your own code, then request, 
   args, and kwargs are not available on the request, so anything that depends 
   on them being there (such as self.get_object()) will not work, so it must 
   be re-implemented, 
   - Otherwise you have to set request, args, kwargs yourself which does 
   not feel very DRY.
   
For me, the entire reason I would like this change, is so that I can do 
something before dispatch that uses self.request/args/kwargs.  Everything I 
want can be accomplished within dispatch, but not as cleanly, or as DRY as 
if this method hook existed.

On Wednesday, November 14, 2012 6:49:06 AM UTC-7, Daniel Sokolowski wrote:
>
>   Can you elaborate the nasty side effects you are thinking of? I can’t 
> think of any that that the base views do to warrant your statement. 
>  
>  *From:* Aaron Merriam  
>  *Sent:* Friday, November 09, 2012 3:12 PM
> *To:* django-d...@googlegroups.com  
> *Subject:* Re: Class based views: A standard hook for 
> http-method-independent code
>  
> That pattern has nasty side-effects.  It can be used in some cases but it 
> fails in most.
>
> On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote: 
>>
>>   I’ve done the below in the past, the only issue with that is if you 
>> have side effects in parent’s dispatch you don’t want executed but you 
>> would also run that risk if you had an initialize() method work flow; in 
>> the end I find dispatch() is enough in my experience. 
>>  
>> def dispatch(self, request, *args, **kwargs):
>> parent_dispatch_return = super(Class, self).dispatch(request, *args, 
>> **kwargs)
>> ...my code based on values based on the super call...
>> return parent_dispatch_return
>>   
>>  *From:* Jordan Hagan 
>> *Sent:* Friday, November 09, 2012 12:37 AM
>> *To:* django-d...@googlegroups.com 
>> *Subject:* Re: Class based views: A standard hook for 
>> http-method-independent code
>>  
>> Hey Russ, 
>>  
>> The main point of concern which I think you may be missing is that 
>> self.kwargs and self.args are set inside dispatch, so using other mixins 
>> that require self.kwargs and self.args to be set (most do) will not work, 
>> without doing:
>>  
>> def dispatch(self, request, *args, **kwargs):
>> self.args = args;
>> self.kwargs = kwargs
>> self.init()
>> return super(Class, self).dispatch(request, *args, **kwargs)
>>  
>> Which isn't very tidy, to me having self.args and self.kwargs be set 
>> twice (once in my overridden dispatch method, and once in the original 
>> dispatch) feels wrong. I can't give you a good reason for it, it just feels 
>> bad every time I do it. The only way to work around this is to override 
>> dispatch without calling the original, and essentially duplicate the 
>> original dispatch method with an init call added in.
>>  
>> Cheers,
>> Jordan
>>   
>> On Fri, Nov 9, 2012 at 6:25 PM, Russell Keith-Magee <
>> rus...@keith-magee.com> wrote:
>>
>>>
>>>
>>>  On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam wrote:
>>>
>>>> Without setting request, args, and kwargs on on the view instance 
>>>> (which is done during the base dispatch view), anything in the view that 
>>>> assumes these values are present cannot run.   
>>>>  
>>>> Most of my views end up with functions which retrieve an object and 
>>>> then do some basic validation to ensure that a user has permissions, or 
>>>> that the object is valid in some fashion, or that some set of conditions 
>>>> is 
>>>> met prior to allowing any method call to happen.  
>>>>  
>>>> I have found that without this init method, the vast majority of my 
>>>> views end up re-writing dispatch which includes the super call.  This is 
>>>> especially annoying when you have to compare some aspect of the requesting 
>>>> user with an object that must be looked up with something from args or 
>>>> kwargs.  My view often already has this machinery built in, but it can't 
>>>> function without dispatch setting request, args, and kwargs, so to 
>>>> accomplish my check, I have to duplicate the lookup code in my dispatch 
>>>> method.
>>>>  
>>>> I don't propose mine is the best solution, but I know that it is 
>>>> non-intrusive, simple, and covers

Re: Class based views: A standard hook for http-method-independent code

[Aaron Merriam]

This is great.  +1.  Better than an additional hook.

On Friday, November 16, 2012 7:09:40 AM UTC-7, Daniel Sokolowski wrote:
>
>   I like this approach. 
>   
>  *From:* George Hickman  
> *Sent:* Thursday, November 15, 2012 7:27 AM
> *To:* django-d...@googlegroups.com  
> *Subject:* Re: Class based views: A standard hook for 
> http-method-independent code
>  
> I have a slightly different proposal, one where we can avoid the extra 
> hook but hopefully cover everyone's use cases too. 
>  
>
> https://github.com/ghickman/django/commit/85ac39a481074c25af1ed72a7a12e62ff5425e54
>  
> I've personally never liked the setting of args, kwargs & request from 
> within dispatch since it seems like it's feature creep of the dispatch 
> method. However I'm also in the same boat as many of the other posters here 
> in needing to do permissions related checks before dispatch is called.
>  
> With my suggestion above you would be able to put your pre-dispatch code 
> in a subclasses overridden dispatch before calling super while also 
> depending on args, kwargs & request on self.
>

-- 
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/-/sOm0GyJ8n2UJ.
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: Status of ticket #14087 - management commands in namespace packages

[Aaron Merriam]

bump.  Any chance we can get this looked at?

On Thursday, September 13, 2012 2:55:56 PM UTC-6, Aaron Merriam wrote:
>
> I'm curious if someone can shed some light on ticket #14087 (
> https://code.djangoproject.com/ticket/14087)
>
> It appears there is a pull request open on github to fix this issue (
> https://github.com/django/django/pull/178)
>
> This recently became a problem when we separated out a few apps into 
> individual packages under the same namespace and there doesn't appear to be 
> any sane way to monkeypatch around the issue.
>

-- 
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/-/EfZlfv-HnpUJ.
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: ModelForm API improvements

[Aaron Merriam]

+1

This would be great.

On Thursday, March 7, 2013 12:42:29 PM UTC-7, Bruno Renié wrote:
>
> Hello, 
>
> There was some discussion on the current limitations of the ModelForm 
> API in the past couple of days on IRC, I'd like to make a proposal to 
> address some of them. 
>
> I wrote django-floppyforms, a library that lets you render forms using 
> templates instead of python code. It behaves exactly like the Django 
> forms library, the only difference is the import path. Import 
> `floppyforms as forms` and when you render a form, the HTML code comes 
> from templates. 
>
> There is still a limitation with ModelForms: since there is no way to 
> globally override the model field -> form field/widget mapping since 
> ModelForms fields come from the model definition. I documented this 
> here: 
>
>
> http://django-floppyforms.readthedocs.org/en/latest/differences.html#modelforms
>  
>
> It is possible to override widgets using the Meta.widgets dict but not 
> in a way that would switch all the ModelForm's fields to 
> template-based widgets automatically. The idea is to have custom 
> ModelForm subclasses with specific strategy on the model field -> form 
> field mapping. 
>
> This is currently possible using something called `formfield_callback` 
> as a ModelForm class attribute: it is simply a callback that takes a 
> db field and returns a form field. But this callback is a) private and 
> b) limited: it gets lost in the inheritance chain as described in 
> ticket #12915: 
>
> https://code.djangoproject.com/ticket/12915 
>
> A discussion thread was started a couple of days ago for a design 
> decision about formfield_callback: should we consider its behaviour as 
> buggy or leave it as it is? In fact formfield_callback is only used by 
> the admin, which has custom widgets for pretty much every db field. 
> This customization is done using the following methods and attributes 
> (all in django/contrib/admin/options.py): 
>
> FORMFIELD_FOR_DBFIELD_DEFAULTS 
> ModelAdmin.formfield_overrides 
> ModelAdmin.formfield_for_dbfield(db_field, **kwargs) 
> ModelAdmin.formfield_for_choicefield(db_field, **kwargs) 
> ModelAdmin.formfield_for_foreignkey(db_field, **kwargs) 
> ModelAdmin.formfield_for_manytomany(db_field, **kwargs) 
>
> In most cases those methods end up calling formfield() on the DB field 
> object, with some arguments for customizing the field class (wrongly 
> called `form_class`) and its constructor arguments (widget, label, 
> help_text, required, etc). 
>
> The arguments to db_field.formfield() are passed via the 
> formfield_callback function I mentioned earlier. 
>
> My proposal is to move that field customization API from the 
> ModelAdmin class back to ModelForm: 
>
> * Move formfield_for_* to ModelForm and document them as public APIs 
> * Deprecate `formfield_callback` 
> * Write an AdminModelForm class that implements all the admin form 
> fields and widgets customization 
> * Modify ModelAdmin to make use of that base class 
> * (maybe?) deprecate ModelForm.Meta.widgets in favor of something 
> similar to the admin's formfield_overrides, which is more generic. 
>
> I see the following advantages to this: 
>
> * This would allow people to have "site-wide" fields/widgets 
> overrides, which is a feature that the admin is already proving 
> useful. Write a nice date picker once, register it for all your 
> DateFields globally. 
>
> * Maintainers of form libraries can ship a base ModelForm class that 
> implements custom fields/widgets while keeping API compatibility with 
> Django. 
>
> Backwards-compatibility shouldn't be an issue as this touches only a 
> couple of ModelAdmin methods. Regarding formfield_callback, despite it 
> being a private API I'm not sure it can be removed safely. There are 
> references to it on StackOverflow and on the Django bug tracker. 
>
> I'm happy to work on a patch if core devs agree to accept this. Thoughts? 
>
> Regards, 
> Bruno 
>

-- 
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: ValidationError for fields

[Aaron Merriam]

+1 on a better way to do field errors.

An alternate would be to implement a method that does this.

def field_error(self, name, error):
> self._errors = self._errors or ErrorDict()
> self._errors.setdefault(name, ErrorList())
> self._errors[name].append(error)


Having to raise a ValidationError would prevent you from creating multiple 
field errors from within `clean`. 

On Monday, August 19, 2013 6:58:25 PM UTC-6, Simon Litchfield wrote:
>
> Lack of clean control over field-specific form errors is an issue that has 
> been raised and discussed many times over the years, but still the solution 
> seems pretty inadequate. We're even directing people hack around with 
> _errors and making excuses for it in the documentation.
>
> https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors
>
> What about an optional kwarg on ValidationError? Eg, raise 
> forms.ValidationError('This field is seriously not cool', field='myfield'). 
> Current 
> behaviour as-is.
>

-- 
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: AbstractUser to get more abstract

[Aaron Merriam]

Check out django-authtools

https://django-authtools.readthedocs.org/en/latest/

Provides a few abstract base classes that make this very easy to 
accomplish.  I'm sure there are other 3rd party apps doing the same.


On Thursday, September 12, 2013 2:44:53 PM UTC-6, Abdulaziz Alfoudari wrote:
>
> This is a continuation of my post on 
> stackoverflow
> .
>
> With the introduction of Django 1.5, it was possible to create a custom 
> User model which is flexible enough to have any user profile the developer 
> wants created. However, looking at a very common problem which is using the 
> email as the primary user identifier instead of username, the solution 
> requires copying most of Django's internal definition of AbstractUser and 
> that is only to remove the username field.
>
> A better solution in my opinion is make AbstractUser even more abstract by 
> removing username field, and allowing the developer to explicitly specify 
> the field to be used as the user identifier. This will require a tiny extra 
> work for those that use the current default behavior, but it will also 
> greatly reduce the work needed for the very common problem of using email 
> as the user identifier.
>
> Please share your thoughts and opinions on this.
>

-- 
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: AbstractUser to get more abstract

[Aaron Merriam]

 That said, I would start by comparing APIs.
>>> That allow us to have a solid ground on what there is already out there, 
>>> to see if any of the existing apps fulfils our expectations of what we 
>>> would like to have in the core.
>>>
>>> I tried to clone your branch ticket_20824 from github to compare your 
>>> app with django-authtools, but it is (far) behind Django master branch, 
>>> which is causing merge conflicts that I don't know how to resolve (because 
>>> I don't know what you are exactly doing).
>>> Maybe I'm doing something wrong or I don't know enough of git, but could 
>>> you please tell us (or maybe is just me that need to be told!) how can we 
>>> compare your patch with Django-master?
>>>
>>> Let me try to give an example:
>>>
>>> After taking a look at 
>>> github.com/Liberationtech/django-libtech-emailuser, the following are 
>>> the main differences and similarities with django-authtools.
>>> Please notice that I'm a (so far) 1-time comitter of django-authtools, 
>>> so take this comparison with appropriate care as I'm certainly biased.
>>>
>>> Where they are *similar*:
>>>
>>> 1. Both are subclasses of AbstractBaseUser and PermissionsMixin (thus 
>>> allow permissions API to be used)
>>>
>>> 2. Both implement the required forms for creation, change, passwordReset.
>>>
>>> 3. Both implement admin interface
>>>
>>> Where they are *different*:
>>>
>>> 1. Models implementation:
>>>
>>> emailuser uses one model with 3 fields: email, first_name, last_name 
>>> (USERNAME_FIELD = 'email)
>>>
>>> django-authtools uses defines three models: 
>>>
>>> A. AbstractUserMail (with one field 'email', like emailuser),
>>> B. AbstractNamedUser, derived from AbstractUserMail with an additional 
>>> field "name". 
>>> C. User, derived from AbstractNamedUser, which is swappable and 
>>> non-abstract.
>>>
>>> 2. django-authtools has tests, emailuser doesn't
>>>
>>> 3. django-authtools is documented, emailuser doesn't
>>>
>>> 4. django-authtools implements views, emailuser doesn't.
>>>
>>> 5. they have different licences, but I don't know enough about them to 
>>> know what are the differences.
>>>
>>> 6. django-authtools passes on travis-ci.org tests, and, as far as I 
>>> know, enforces clean commit history (don't know if it is relevant thought).
>>>
>>> 7. usermail has a form to ask reset-password (by email?), but I didn't 
>>> found any implementation of the actual reset.
>>>
>>>
>>> Tom, would you be willing to provide the differences and similarities of 
>>> your API with django-authtools and emailuser, or teach me how can I compare 
>>> it against django-master so I can make a comparison?
>>> It would be nice to have your API documented here so we can take the 
>>> most out of the all existing implementations.
>>>
>>> Best regards,
>>> Jorge
>>>
>>> On Sep 16, 2013, at 10:04 PM, tanderegg  wrote:
>>>
>>> Hey folks - I took a crack at implementing this, please check out my 
>>> comment here (which contains a link to the branch in my fork): 
>>> https://code.djangoproject.com/ticket/20824#comment:4
>>>
>>> Let me know if I missed anything!
>>>
>>> Tim
>>>
>>> On Friday, September 13, 2013 1:03:23 AM UTC-4, Aaron Merriam wrote:
>>>>
>>>> Check out django-authtools
>>>>
>>>> https://django-authtools.readthedocs.org/en/latest/
>>>>
>>>> Provides a few abstract base classes that make this very easy to 
>>>> accomplish.  I'm sure there are other 3rd party apps doing the same.
>>>>
>>>>
>>>> On Thursday, September 12, 2013 2:44:53 PM UTC-6, Abdulaziz Alfoudari 
>>>> wrote:
>>>>>
>>>>> This is a continuation of my post on 
>>>>> stackoverflow<http://stackoverflow.com/questions/18769729/django-removing-username-from-user-model>
>>>>> .
>>>>>
>>>>> With the introduction of Django 1.5, it was possible to create a 
>>>>> custom User model which is flexible enough to have any user profile the 
>>>>> developer wants created. However, looking at a very common problem 

Re: AbstractUser to get more abstract

[Aaron Merriam]

Russel, I'm curious if you could expand/explain your motivation on having 
this implemented as a separate contrib application rather than including it 
with django.contrib.auth

On Thursday, September 12, 2013 5:41:29 PM UTC-6, Russell Keith-Magee wrote:
>
>
> On Fri, Sep 13, 2013 at 4:44 AM, Abdulaziz Alfoudari 
> 
> > wrote:
>
>> This is a continuation of my post on 
>> stackoverflow
>> .
>>
>> With the introduction of Django 1.5, it was possible to create a custom 
>> User model which is flexible enough to have any user profile the developer 
>> wants created. However, looking at a very common problem which is using the 
>> email as the primary user identifier instead of username, the solution 
>> requires copying most of Django's internal definition of AbstractUser and 
>> that is only to remove the username field.
>>
>> A better solution in my opinion is make AbstractUser even more abstract 
>> by removing username field, and allowing the developer to explicitly 
>> specify the field to be used as the user identifier. This will require a 
>> tiny extra work for those that use the current default behavior, but it 
>> will also greatly reduce the work needed for the very common problem of 
>> using email as the user identifier.
>>
>> Please share your thoughts and opinions on this.
>>
>
> The short answer: this isn't going to happen. AbstractUser is a released 
> and documented API, so we're not in a position to change it in the way you 
> describe without causing massive inconvenience to everyone that is using it 
> at present (at least, I don't see an obvious way that this could be done).
>
> However, ticket #20824 describes a proposal to add an email-login analog 
> of Django's built-in user. This would make introduction of email-based 
> login a matter of 2 lines of configuration. This ticket is really just 
> waiting on someone to prepare a patch… and it should be a relatively simple 
> patch to prepare. If you're looking to get involved in Django development, 
> this would be an easy place to start.
>
> 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.

Re: AbstractUser to get more abstract

[Aaron Merriam]

Luke, I'm +1 on wanting a solution that allows "just set AUTH_USER_MODEL to 
'auth.EmailUser', and done".

It'd be nice if 'swappable' could accomplish this for us.  Something along 
the lines of for any set of swappable models which are swappable for the 
same settings value, only load the one that is named by the settings value. 
 I am taking some time to read the source surrounding this setting and 
model loading to even figure out if this is a possible modification. 
 Russel, curious about your thoughts on if this approach would be something 
you would sign off on.

This seems like a good compromise over adding infrastructure for not 
installing certain models.  This would instead create infrastructure to 
declare a certain 'type' of model must be present, but that you may decide 
which one based on a settings value.

This approach feels cleaner to me because we don't want to 'turn off' a 
model, but rather only load a single 'User' model from some set of 'User' 
models.  In the case of 'User', we need at least one 'User' model to be 
loaded, and this enforces that, where as the ability to turn off certain 
models could introduce situations in which someone turns off a model 
without replacing it.

Aaron Merriam

On Wednesday, September 18, 2013 1:39:16 PM UTC-6, Luke Sneeringer wrote:
>
> I added the authtools approach to the wiki for completion, although I 
> believe it to be an inferior approach.
>
> One thing I dislike is having a separate app (e.g. d.c.auth_email) that 
> has to be installed separately. That feels pretty impure to me. I'm doing a 
> thought exercise about potential solutions, though, and not exactly coming 
> up aces.
>
> The best solution I can currently think of is to have User and EmailUser 
> which are both models that live in django.contrib.auth. Then, we would have 
> to add code to our model detection that says that *if* a model is a 
> subclass of AbstractBaseUser, include it if and only if it is the 
> AUTH_USER_MODEL.
>
> I can't decide if that solution is better or worse than the disease. It 
> makes for a much more attractive set of steps to follow for people who want 
> to use it, though -- basically, just set AUTH_USER_MODEL to 
> 'auth.EmailUser', and done.
>
> Thoughts?
>
> Best Regards,
> Luke Sneeringer
>
> On September 18, 2013 at 7:17:53 AM, Timothy Anderegg (
> timothy@gmail.com ) wrote:
>
> Hi all - I updated Russ's new wiki page to include the work I've done so 
> far: https://code.djangoproject.com/wiki/ContribEmailAuth  Again, the 
> patch I've been working on is here: 
> https://github.com/tanderegg/django/tree/ticket_20824_master  Please let 
> me know if you have any feedback.
>
> The only real other option (that I can see) would be to do something more 
> extensive like django-authtools (
> https://django-authtools.readthedocs.org/en/latest/).  I can write up a 
> description of this approach as well if that would be useful, although I 
> did write up a description of the difference between my code and the two 
> other existing django apps in a post earlier in this thread.
>
> Thanks,
>
> Tim
>
>
> On Wed, Sep 18, 2013 at 1:42 AM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>> On Wed, Sep 18, 2013 at 1:27 PM, Luke Sneeringer 
>> 
>> > wrote:
>>
>>> Russell,
>>> I would *love* to do the work for the email-login analogue you 
>>> describe. I actually proposed just such a thing a few months ago but was 
>>> rebuffed. 
>>>
>>
>> I'm sorry to hear this. Out of interest, did a member of the core team 
>> actually say "no", or was it just a matter of proposing something and not 
>> getting traction? 
>>
>> If it was the latter, it's important to remember that the core team are 
>> all volunteers, and sometimes the spare time of the core team doesn't 
>> necessarily match up with the spare time of volunteers in the wider 
>> community. As a result, well intentioned and desired work sometimes gets 
>> ignored. It's not (necessarily) being ignored because it was bad -- often 
>> it's just "we don't have enough cycles *right now*.
>>   
>>
>>> However, I think this would be extremely useful. Also, I am, in fact, 
>>> looking to get involved with Django development, as I haven't quite 
>>> navigated the hurdles successfully.
>>>
>>> I do have one request, though. Is there a core developer that would be 
>>> willing to "mentor" my work on this, so I can make sure I am writing 
>>&g

Re: AbstractUser to get more abstract

[Aaron Merriam]

I and my colleague (gavinw...@gmail.com) have made some edits to the wiki 
to clarify the purpose of authtools, and more accurately explain what the 
'authtools' approach would look like.  If you previously have examined 
'option 2', I would ask that you go and reread that section in the wiki.

https://code.djangoproject.com/wiki/ContribEmailAuth

The problem you've got here is how it knows to *not* install EmailUser. If 
> it's a model defined in d.c.auth.models, it will get installed, 
> irrespective of whether it is AUTH_USER_MODEL or not.


I wanted to verify this so I ran some basic tests and turns out that 
swappable already does the correct thing.  If two models have the same 
swappable value, only the one referenced in settings will be 
used/installed.  This makes it practical to include a second user model in 
d.c.auth.models without any changes to model loading or the swappable 
mechanism.

Refactoring d.c.auth is a low impact way to facilitate custom user models 
including and beyond email as username.  We would much rather see d.c.auth 
become more generic and more abstract, than see a new contrib app built 
specifically for email as username.  Russell stated that this issue was 
more than just about the user model, that it included forms, views, urls, 
etc.  If there is a solution which allows for views, forms, urls, etc to be 
shared, I would prefer that approach over adding a new app.

-- 
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: AbstractUser to get more abstract

[Aaron Merriam]

>
> I'm not sure it was the intention in the design of swappable.


I don't know the intended use of swappable, but this seems like exactly the 
type of thing that a 'swappable' model should be able to do.
 

> However, we still have the issue of different forms, urls, views etc all 
> based off the changed model.


Marc, can you explain why you feel we need different forms, urls, views, 
etc.  The only forms that would not work appropriately with EmailUser would 
be UserCreation and UserChange forms, both of which can be modified to work 
correctly with EmailUser or other custom user models .  The views in 
d.c.auth all work correctly with the proposed EmailUser and most custom 
user models.   The urls in d.c.auth are not concerned with the username 
field so I don't see an issue there.  The ModelAdmin class in d.c.auth can 
also be modified to respect USERNAME_FIELD and work with EmailUser.

 Making these change automatically would be horrible.


Can you explain why this would be horrible.  The changes proposed in the 
'authtools' style approach make d.c.auth more abstract in ways that make 
using a custom user model easier, while still keeping d.c.auth functioning 
the same when the user has not been swapped out.  To me, this is a step 
towards making custom user models easier and thus, a bonus.

-- 
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: AbstractUser to get more abstract

[Aaron Merriam]

>
> However, if auth.User (or any other model for that matter) is set as 
> AUTH_USER_MODEL, nothing prevents EmailUser from being installed.
>

The current behavior of swappable is that if two models are swappable on 
the same settings value, only the one designated by the settings value will 
be installed.  So, currently, in django if I add the concrete model 
EmailUser to django.contrib.auth.models with swappable='AUTH_USER_MODEL', 
and do nothing else, this model is not installed.  If I reset my database 
and set my settings.AUTH_USER_MODEL to 'auth.EmailUser', then EmailUser 
will be installed and 'django.contrib.auth.User' will not be installed. 
 This is the current behavior of swappable based on my testing.

So there is no need for new internal mechanisms to control whether a model 
is installed or not, as that mechanism already exists within the current 
behavior of swappable.

On Thursday, September 19, 2013 5:09:10 PM UTC-6, Russell Keith-Magee wrote:
>
>
> On Thu, Sep 19, 2013 at 9:41 PM, Marc Tamlyn 
> > wrote:
>
>> The problem you've got here is how it knows to *not* install EmailUser. 
>> If it's a model defined in d.c.auth.models, it will get installed, 
>> irrespective of whether it is AUTH_USER_MODEL or not. This is where we have 
>> to special case the new model somehow so it is only installed if we are 
>> using it. This is far from straightforwards! By putting it in a separate 
>> app which is not installed by default, then we solve this issue trivially 
>> without more magic.
>>
> Elaborating on this point: it's not just the models, either -- it's views, 
> admin registrations, forms, and potentially URLs.
>
> There's also a matter of consistency. We have to ship a default User 
> model. We've set up a system that encourages people to develop their own 
> user models. If you develop a third party User model, you need to do two 
> things -- register the app, and declare AUTH_USER_MODELS. It seems 
> completely logical to me that an EmailUser app that we're shipping as part 
> of Django should be expected to do the same. 
>
> If nothing else, it means we can point at contrib.email_auth and say 
> "that's how you do it!".
>  
>
>>  On 19 Sep 2013 05:27, "Luke Sneeringer" > 
>> wrote:
>>
>>> Bah, I should have planned my e-mailing better. Sorry for sending a 
>>> third in such rapid succession.
>>>
>>> I just did some checking into my assumptions (quoted below) on this. It 
>>> turns out that Django core already does some of what I suggest: in 
>>> particular, it doesn't install the User model if django.contrib.auth is 
>>> installed but another AUTH_USER_MODEL is invoked, based on a Meta option 
>>> called "swappable" (see [here][1] and [here][2]).
>>>
>>> Am I misunderstanding? It seems like we are already pretty well down my 
>>> proposed path.
>>>
>>  
> You've correctly identified the current behaviour, but you're 
> extrapolating in a direction that isn't possible (at least, not with the 
> current infrastructure).
>
> You're correct in saying auth.User won't be installed if another model is 
> set as AUTH_USER_MODEL. However, if auth.User (or any other model for that 
> matter) is set as AUTH_USER_MODEL, nothing prevents EmailUser from being 
> installed. This is because there's no artefact on the "plugged" model that 
> says "I'm a candidate for being a pluggable User. *Any* model *could* be 
> installed as a User -- you don't have to predeclare "I'm a candidate for 
> being a User". Therefore, we have no metadata basis on which to say "Oh, 
> I'm not being used as a pluggable model, don't install me." 
>
> We *could* add this metadata, but again -- we'd be adding metadata and a 
> bunch of complex internals as a workaround for asking users to put an app 
> in INSTALLED_APPS, and set AUTH_USER_MODEL. For my money, the cost vastly 
> exceeds the questionable benefit.
>
> 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.

Re: AbstractUser to get more abstract

[Aaron Merriam]

Russell, my reply there isn't meant to be confrontational and yet 
re-reading it I can see it being easily interpreted as such.  My intention 
is to ask whether there is something about swappable that I am missing.  It 
seems to work the way I stated above but your statement seems to imply that 
their is some missing piece that needs extra mechanisms surrounding model 
loading.  So, am I missing something?

Marc,

Thank you for your reply, and I respect the difference of opinion.  If I 
understand you correctly, you feel that this belongs in a separate contrib 
application because to refactor auth to be generic enough to handle both 
the built in User and EmailUser will involve too much magic.

I'm curious if you've taken a look at the code behind django-authtools.  I 
feel that it is a good example of what some of the changes to auth.forms or 
auth.views might look like, and that there is less 'magic' involved than 
you might think.

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