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.

Google groups - possible issues with deleted posts.

[Tom Christie]

Be aware that there may be issues with google groups at the moment...

There are two messages in this 
thread
 that 
are marked as deleted, apparently not 
intentionally
.
There are also three messages in this 
thread,
 
all around the same timeframe which are marked as deleted, which seems a 
little suspect.
I've also seen one message on a group I manage marked as 
deleted,
 
again around the same timeframe, and without any action by the sender of 
the message or by myself.

It is of course not impossible that there's been a spate of moderator 
and/or user error, but it does seem like google groups is probably being a 
bit wonky.

Probably worth keeping an eye out for similar behavior.

-- 
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/-/t295xrxODN8J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Admin Revamp - Any updates?

[Christian Bertschy]

Hi everyone

At Divio we are working on a new look of the Django Admin for our projects. 
To be clear, it's just the looks. I agree 100% with Idan that a real revamp 
should consider not only the looks but also rethink the way the admin works 
(and we all know that this is a huge difference :-)). 

But in the meantime: https://github.com/divio/djangocms-admin-style

It's still in beta, but feel free to use it or even better contribute to it.

Here are some screenshots:
https://www.dropbox.com/sh/oicwr3g4wu9x1z1/VymKkK2FZM

Have fun,

Christian


On Friday, April 27, 2012 1:06:06 AM UTC+2, Victor Hooi wrote:
>
> Hi,
>
> Is there any news on the Django Admin rewrite front?
>
> I remember around a year ago, there was quite a bit of talk on revamping 
> the Django admin UI - I think Idan Gazit was heading that, right?
>
> Is that still on the Django roadmap? Any idea of whether it'll be in 1.5, 
> 1.6, 1.7 etc?
>
> Cheers,
> Victor
>

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

[Daniel Sokolowski]

I like this approach. 

From: George Hickman 
Sent: Thursday, November 15, 2012 7:27 AM
To: django-developers@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.

On Thursday, November 15, 2012 4:18:34 AM UTC, Aaron Merriam wrote: 
  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.   

a.. 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,  
b.. 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 
 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 

Re: Django Admin Revamp - Any updates?

[Christian Bertschy]

Sorry, the google drive link needs a login and google doesn't allow me to 
change that :-)

Therefore the dropbox link: 
https://www.dropbox.com/sh/oicwr3g4wu9x1z1/VymKkK2FZM

On Friday, November 16, 2012 9:25:32 AM UTC+1, Christian Bertschy wrote:
>
> Hi everyone
>
> At Divio we are working on a new look of the Django Admin for our 
> projects. To be clear, it's just the looks. I agree 100% with Idan that a 
> real revamp should consider not only the looks but also rethink the way the 
> admin works (and we all know that this is a huge difference :-)). 
>
> But in the meantime: https://github.com/divio/djangocms-admin-style
>
> It's still in beta, but feel free to use it or even better contribute to 
> it.
>
> Here are some screenshots:
>
> https://docs.google.com/a/divio.ch/folder/d/0BzukahwPSnHuVjZWdUtrcndBUVE/edit
>
> Have fun,
>
> Christian
>
> On Friday, April 27, 2012 1:06:06 AM UTC+2, Victor Hooi wrote:
>>
>> Hi,
>>
>> Is there any news on the Django Admin rewrite front?
>>
>> I remember around a year ago, there was quite a bit of talk on revamping 
>> the Django admin UI - I think Idan Gazit was heading that, right?
>>
>> Is that still on the Django roadmap? Any idea of whether it'll be in 1.5, 
>> 1.6, 1.7 etc?
>>
>> Cheers,
>> Victor
>>
>

-- 
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/-/ByAfFurcJ0QJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Admin Revamp - Any updates?

[Christian Bertschy]

Sorry, the google drive link needs a login and google doesn't allow me to 
change that :-)

Therefore the dropbox 
link: https://www.dropbox.com/sh/oicwr3g4wu9x1z1/VymKkK2FZM

On Friday, April 27, 2012 1:06:06 AM UTC+2, Victor Hooi wrote:
>
> Hi,
>
> Is there any news on the Django Admin rewrite front?
>
> I remember around a year ago, there was quite a bit of talk on revamping 
> the Django admin UI - I think Idan Gazit was heading that, right?
>
> Is that still on the Django roadmap? Any idea of whether it'll be in 1.5, 
> 1.6, 1.7 etc?
>
> Cheers,
> Victor
>

-- 
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/-/OdF_1oUOBn4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Admin Revamp - Any updates?

[Christian Bertschy]

Hi everyone

At Divio we are working on a new look of the Django Admin for our projects. 
To be clear, it's just the looks. I agree 100% with Idan that a real revamp 
should consider not only the looks but also rethink the way the admin works 
(and we all know that this is a huge difference :-)). 

But in the meantime: https://github.com/divio/djangocms-admin-style

It's still in beta, but feel free to use it or even better contribute to it.

Here are some screenshots:
https://docs.google.com/a/divio.ch/folder/d/0BzukahwPSnHuVjZWdUtrcndBUVE/edit

Have fun,

Christian

On Friday, April 27, 2012 1:06:06 AM UTC+2, Victor Hooi wrote:
>
> Hi,
>
> Is there any news on the Django Admin rewrite front?
>
> I remember around a year ago, there was quite a bit of talk on revamping 
> the Django admin UI - I think Idan Gazit was heading that, right?
>
> Is that still on the Django roadmap? Any idea of whether it'll be in 1.5, 
> 1.6, 1.7 etc?
>
> Cheers,
> Victor
>

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

[George Hickman]

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.

On Thursday, November 15, 2012 4:18:34 AM UTC, Aaron Merriam wrote:
>
> 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 
>