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

2012-11-12 Thread Diederik van der Boor 
Op 9 nov. 2012, om 07:05 heeft Russell Keith-Magee het volgende geschreven:

> What I don't understand is why the need for an init() method isn't being 
> challenged in the first place. 
> 
> Why on earth can't just just take the logic that you're putting in init(), 
> and put it *in dispatch()*. The sequence of calls is *identical*, and since 
> *args and **kwargs are locals, they don't need to be set anywhere. What's the 
> problem with putting the init() logic in the dispatch() method in the way I 
> described?
> 

It has to do with the order of execution, the derived class always runs first.
When a permission check is in dispatch(), anything that overrides dispatch() 
runs before the permission check.
The same also applies to any other initialization code, a derived class can 
never build on top of that because it should call


Please allow me to paraphrase my previous explanation 
(https://groups.google.com/d/msg/django-developers/7c7aI-slGNc/a-DYFrIM3ZgJ)


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.



Greetings,

Diederik

-- 
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: ClearableFileInput doesn't render a currently value when invalid

2012-11-12 Thread Hiroki Kiyohara 
Hi, tino. Thanks for your reply. 

I compleatly understood that the problem is known here. 
If I fell like it, I try solving this. 

Thank you. 

hirokiky

-- 
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/-/BgI_ZpGnWHYJ.
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: post-collectstatic signal

2012-11-12 Thread Jannis Leidel 

On 11.11.2012, at 17:09, Justin Holmes  wrote:

> My sense is that there are a growing number of use cases, but the one that I 
> currently have in mind is for django-coldbrew.  I want to be able to 
> compile all the coffeescript in a project during the collectstatic process.  
> Currently, we have a management command, "collect_coldbrew" - but I'd like to 
> allow users to have this occur automatically during collectstatic.

The collectstatic command calls a method "post_process" method [1] of the 
staticfiles storage if it exists and passes a list of file paths that have been 
collected [2].

In other words, hooking into collectstatic is as easy as writing an own 
subclass of StaticFilesStorage (or whatever storage backend you've set 
STATICFILES_STORAGE) and implement the method.

Would that suffice for your use case?

Jannis

1: 
https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.StaticFilesStorage.post_process
2: 
https://github.com/django/django/blob/master/django/contrib/staticfiles/management/commands/collectstatic.py#L116-127

> I'm not sure if the best timing for the signal is at the end of the complete 
> collectstatic process or at the end of each iteration (ie, one signal for 
> each static directory that django finds).
> 
> 
> On Sun, Nov 11, 2012 at 4:55 AM, Alex Gaynor  wrote:
> What's the use case?
> 
> Alex
> 
> 
> On Sat, Nov 10, 2012 at 8:48 PM, Justin Holmes  
> wrote:
> Currently, our only built-in management signal is post-syncdb.
> 
> I propose (and, notwithstanding objection, will build) post-collectstatic.  
> 
> Is this reasonable?  Is there another, less invasive way to hook logic into 
> collectstatic?
> 
> 
> -- 
> Justin Holmes
> Chief Chocobo Breeder, slashRoot
> 
> slashRoot: Coffee House and Tech Dojo
> New Paltz, NY 12561
> 845.633.8330
> 
> -- 
> 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.
> 
> 
> 
> -- 
> "I disapprove of what you say, but I will defend to the death your right to 
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> 
> 
> -- 
> 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.
> 
> 
> 
> -- 
> Justin Holmes
> Chief Chocobo Breeder, slashRoot
> 
> slashRoot: Coffee House and Tech Dojo
> New Paltz, NY 12561
> 845.633.8330
> 
> -- 
> 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: proposal: post-collectstatic signal

2012-11-12 Thread ptone 


On Sunday, November 11, 2012 8:09:23 AM UTC-8, Justin Holmes wrote:
>
> My sense is that there are a growing number of use cases, but the one that 
> I currently have in mind is for django-coldbrew.  I want to be able to 
> compile all the coffeescript in a project during the collectstatic 
> process.  Currently, we have a management command, "collect_coldbrew" - but 
> I'd like to allow users to have this occur automatically during 
> collectstatic.
>

Why not have your collect_coldbrew wrap collectstatic - then you have one 
command?

While there are parts of the staticfiles API that should probably be opened 
more some day - for now it is a relatively private API.  What Bruno has 
suggested uses technically private API.

Such a signal as proposed would seem to be a way around 
https://code.djangoproject.com/ticket/15213 - and introducing a signal for 
such a narrow use is gonna be the wrong way to address this.

There are a couple other alternatives:

A custom storage backend (public API) that does the compiling before 
writing the file (this could feel unintuitive).

or use django-compressor which handles this action via template tags:

http://django_compressor.readthedocs.org/en/latest/settings/#django.conf.settings.COMPRESS_PRECOMPILERS

-Preston


> I'm not sure if the best timing for the signal is at the end of the 
> complete collectstatic process or at the end of each iteration (ie, one 
> signal for each static directory that django finds).
>
>
> On Sun, Nov 11, 2012 at 4:55 AM, Alex Gaynor  > wrote:
>
>> What's the use case?
>>
>> Alex
>>
>>
>> On Sat, Nov 10, 2012 at 8:48 PM, Justin Holmes 
>> > > wrote:
>>
>>> Currently, our only built-in management signal is post-syncdb.
>>>
>>> I propose (and, notwithstanding objection, will build) 
>>> post-collectstatic.  
>>>
>>> Is this reasonable?  Is there another, less invasive way to hook logic 
>>> into collectstatic?
>>>
>>>
>>> -- 
>>> Justin Holmes
>>> Chief Chocobo Breeder, slashRoot
>>>
>>> slashRoot: Coffee House and Tech Dojo
>>> New Paltz, NY 12561
>>> 845.633.8330
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers" group.
>>> To post to this group, send email to 
>>> django-d...@googlegroups.com
>>> .
>>> To unsubscribe from this group, send email to 
>>> django-develop...@googlegroups.com .
>>> For more options, visit this group at 
>>> http://groups.google.com/group/django-developers?hl=en.
>>>
>>
>>
>>
>> -- 
>> "I disapprove of what you say, but I will defend to the death your right 
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
>
>
> -- 
> Justin Holmes
> Chief Chocobo Breeder, slashRoot
>
> slashRoot: Coffee House and Tech Dojo
> New Paltz, NY 12561
> 845.633.8330
>  

-- 
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/-/ae2y0-BLq4UJ.
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: ClearableFileInput doesn't render a currently value when invalid

2012-11-12 Thread Tino de Bruijn 
Hi Hiroki,

On Mon, Nov 12, 2012 at 12:31 PM, Hiroki Kiyohara wrote:

> Hi, all.
>
> Problem
> ===
> In updating objects(UpdateView and so on),
> django.forms.widgets.ClearableFileInput doesn't render a currently value
> when  the POSTed data was invalid(for example, uploading PDF file to
> ImageField using ClearableFileInput).
> The HTML rendered when invalid error is only includes input tag. It's
> natural to render more components ("Currentry: /path/to/spam", clear
> checkbox and so on).
>
> For more detail
> --
> And the input field rendered when invalid error allows empty, even if the
> field is required. And it allows empty submit. In this case, the currently
> value will retain. This behavior is gross. seriously.
>
> Why this happens
> ===
> render method on ClearableFileInput isn't render currently value and
> checkbox when value arg is empty.
> When validation error is raise, the arg will be empty.
>
> Django's version
> ==
> I found this behavior in Django==1.4.1
>
> conclusion
> =
> If you can't understand my poor English or this problem is my
> misunderstanding, sorry, please tell me so.
>
> ---
> Hiroki Kiyohara
> @hirokiky
> http://hirokiky.org/


It appears to me that this is the same issue as described in this ticket
[1] and was referenced a few weeks ago on this mailinglist ([2]). Feel free
to comment on that ticket if you have new insights or a patch.

[1] https://code.djangoproject.com/ticket/19215
[2]
https://groups.google.com/d/topic/django-developers/3lpFZ380dzQ/discussion

Regards,


Tino

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

ClearableFileInput doesn't render a currently value when invalid

2012-11-12 Thread Hiroki Kiyohara 
Hi, all. 

Problem
===
In updating objects(UpdateView and so on), 
django.forms.widgets.ClearableFileInput doesn't render a currently value when  
the POSTed data was invalid(for example, uploading PDF file to ImageField using 
ClearableFileInput). 
The HTML rendered when invalid error is only includes input tag. It's natural 
to render more components ("Currentry: /path/to/spam", clear checkbox and so 
on). 

For more detail
--
And the input field rendered when invalid error allows empty, even if the field 
is required. And it allows empty submit. In this case, the currently value will 
retain. This behavior is gross. seriously.

Why this happens
===
render method on ClearableFileInput isn't render currently value and checkbox 
when value arg is empty. 
When validation error is raise, the arg will be empty.

Django's version
==
I found this behavior in Django==1.4.1

conclusion
=
If you can't understand my poor English or this problem is my misunderstanding, 
sorry, please tell me so. 

---
Hiroki Kiyohara
@hirokiky
http://hirokiky.org/

-- 
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: post-collectstatic signal

2012-11-12 Thread Bruno Renié 
On Sun, Nov 11, 2012 at 5:09 PM, Justin Holmes  wrote:
> My sense is that there are a growing number of use cases, but the one that I
> currently have in mind is for django-coldbrew.  I want to be able to
> compile all the coffeescript in a project during the collectstatic process.
> Currently, we have a management command, "collect_coldbrew" - but I'd like
> to allow users to have this occur automatically during collectstatic.

In this case it seems you could just override the collectstatic
command. That's what contrib.staticfiles does with runserver, which is
a core command that gets overridden when you add the staticfiles app
to your INSTALLED_APPS.

>From the get_commands [0] code it looks like the last app in
INSTALLED_APPS takes precedence, so adding 'coldbrew' after
`staticfiles` in INSTALLED_APPS would override the default
collectstatic command with coldbrew's extended version.

[0] 
https://github.com/django/django/blob/master/django/core/management/__init__.py#L79-123

Bruno

> I'm not sure if the best timing for the signal is at the end of the complete
> collectstatic process or at the end of each iteration (ie, one signal for
> each static directory that django finds).
>
>
>
> On Sun, Nov 11, 2012 at 4:55 AM, Alex Gaynor  wrote:
>>
>> What's the use case?
>>
>> Alex
>>
>>
>> On Sat, Nov 10, 2012 at 8:48 PM, Justin Holmes 
>> wrote:
>>>
>>> Currently, our only built-in management signal is post-syncdb.
>>>
>>> I propose (and, notwithstanding objection, will build)
>>> post-collectstatic.
>>>
>>> Is this reasonable?  Is there another, less invasive way to hook logic
>>> into collectstatic?
>>>
>>>
>>> --
>>> Justin Holmes
>>> Chief Chocobo Breeder, slashRoot
>>>
>>> slashRoot: Coffee House and Tech Dojo
>>> New Paltz, NY 12561
>>> 845.633.8330
>>>
>>> --
>>> 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.
>>
>>
>>
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>>
>> --
>> 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.
>
>
>
>
> --
> Justin Holmes
> Chief Chocobo Breeder, slashRoot
>
> slashRoot: Coffee House and Tech Dojo
> New Paltz, NY 12561
> 845.633.8330
>
> --
> 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.