New patch posted, comments?
On Jan 12, 2:13 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Added a patch that uses the takes_initial approach. The tests pass.
> Just want this in quick ;)
>
> On Jan 11, 4:14 am, Brian Rosner <[EMAIL PROTECTED]> wrote:
>
> > On 2008-01-10 17:34:11 -0700,
Added a patch that uses the takes_initial approach. The tests pass.
Just want this in quick ;)
On Jan 11, 4:14 am, Brian Rosner <[EMAIL PROTECTED]> wrote:
> On 2008-01-10 17:34:11 -0700, Malcolm Tredinnick
> <[EMAIL PROTECTED]> said:
>
>
>
>
>
> > On Thu, 2008-01-10 at 02:12 -0800,
> > [EMAIL
On 2008-01-10 17:34:11 -0700, Malcolm Tredinnick
<[EMAIL PROTECTED]> said:
>
>
> On Thu, 2008-01-10 at 02:12 -0800,
> [EMAIL PROTECTED] wrote:
>> Looked at the latest patch, great stuff.
>>
>> About other fields needing initial data, what about havig a commom
>> baseclass (for use with
On Thu, 2008-01-10 at 02:12 -0800, [EMAIL PROTECTED] wrote:
> Looked at the latest patch, great stuff.
>
> About other fields needing initial data, what about havig a commom
> baseclass (for use with isinstance) for those fields or a
> takes_initial attribute so it is not only specific to
As mentioned om IRC:
About takes_initial, maybe it should just give the field clean a tuple
of (value, initial) to avoid changing the clean arguments?
Not sure if this is a good idea, any core devs have a design decision?
On Jan 10, 5:00 pm, Brian Rosner <[EMAIL PROTECTED]> wrote:
> On
On 2008-01-10 03:12:29 -0700,
"[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> said:
>
> Looked at the latest patch, great stuff.
>
> About other fields needing initial data, what about havig a commom
> baseclass (for use with isinstance) for those fields or a
> takes_initial attribute so it is not
Looked at the latest patch, great stuff.
About other fields needing initial data, what about havig a commom
baseclass (for use with isinstance) for those fields or a
takes_initial attribute so it is not only specific to filefields.
On Jan 10, 1:24 am, Brian Rosner <[EMAIL PROTECTED]> wrote:
>
On 2008-01-09 16:20:39 -0700, Malcolm Tredinnick
<[EMAIL PROTECTED]> said:
>
>
> On Wed, 2008-01-09 at 14:04 -0700, Brian Rosner wrote:
>> On 2008-01-08 18:46:02 -0700, Malcolm Tredinnick
>> <[EMAIL PROTECTED]> said:
>>
>>>
>>>
>>> On Tue, 2008-01-08 at 18:40 -0700, Brian Rosner wrote:
>>>
On Wed, 2008-01-09 at 14:04 -0700, Brian Rosner wrote:
> On 2008-01-08 18:46:02 -0700, Malcolm Tredinnick
> <[EMAIL PROTECTED]> said:
>
> >
> >
> > On Tue, 2008-01-08 at 18:40 -0700, Brian Rosner wrote:
> > [...]
> >
> >> To write a patch I created a new widget named BoundFileInput that
>
On 2008-01-08 18:46:02 -0700, Malcolm Tredinnick
<[EMAIL PROTECTED]> said:
>
>
> On Tue, 2008-01-08 at 18:40 -0700, Brian Rosner wrote:
> [...]
>
>> To write a patch I created a new widget named BoundFileInput that
>> inherits from MultiWidget to display the FileInput and HiddenInput
>>
On Tue, 2008-01-08 at 18:40 -0700, Brian Rosner wrote:
[...]
> To write a patch I created a new widget named BoundFileInput that
> inherits from MultiWidget to display the FileInput and HiddenInput
> widgets. The FileInput widget works the same as it does now. The
> HiddenInput widget
It appears that the usage of FileField with ModelForm is not working
correctly. [1] is the ticket in Trac. The problem, put briefly, is that
when a ModelForm is given an instance it is marked as required and
requires the user to upload a file to bypass the validation. Keep in
mind
12 matches
Mail list logo
