On 9/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Model validation isn't something that needs to be run constantly.
> Strictly, it only needs to be run once - when syncdb is run - to make
> sure that the model isn't broken. Once the model has been validated,
> there isn't any need to re-
On 9/5/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> I normally hate to "ping" discussions on mailing lists, but two weeks
> have passed, and I was hoping I could get an answer to the biggest
> question facing this discussion. Adrian, could you clarify what you
> meant by "loaded into memory" me
I normally hate to "ping" discussions on mailing lists, but two weeks
have passed, and I was hoping I could get an answer to the biggest
question facing this discussion. Adrian, could you clarify what you
meant by "loaded into memory" means exactly, in this context? Are you
referring to loading th
Am 21.08.2007 um 04:54 schrieb Marty Alchin:
> On 8/20/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>> There is indeed a reason: model field validation logic is in a
>> separate module so that the logic doesn't have to be loaded into
>> memory when you're using Django in production. As it stands
On 8/20/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> There is indeed a reason: model field validation logic is in a
> separate module so that the logic doesn't have to be loaded into
> memory when you're using Django in production. As it stands, the
> validation code is only loaded when you us
On 8/20/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> There is indeed a reason: model field validation logic is in a
> separate module so that the logic doesn't have to be loaded into
> memory when you're using Django in production. As it stands, the
> validation code is only loaded when you us
On 8/20/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Is there a particular reason this validation is being performed there
> instead of in the __init__ of each Field subclass? I haven't looked
> over the entirety of it, but it seems like that's going to be
> something of a barrier to custom subcl
On 8/20/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Now, as you correctly identify, this isn't really the right approach.
> We have been slowly refactoring fields, with the end goal of allow any
> user to define their own fields wrapping whatever database specific
> types may be available
On 8/21/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Is there a particular reason this validation is being performed there
> instead of in the __init__ of each Field subclass? I haven't looked
> over the entirety of it, but it seems like that's going to be
> something of a barrier to custom subc
On 8/20/07, Etienne Robillard <[EMAIL PROTECTED]> wrote:
> Again, we should probably "see" better your problem with some raw examples. :)
> Why should you need any management-specific methods for doing validation on
> a file field ?
>
> from django.newforms import fields
> class GenericFile(fields
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Not sure what to expect unless you give some more data, input,
or whatever which should make senses regarding your issue with FileField.
However, in my case i've managed to make FileField working
reasonably well using the newforms-admin branch. I s
In trying to refactor FileField into a self-contained entity (and
allow exchangable backends), I ran across something I didn't remotely
expect.
I have a nearly-complete drop-in replacement for the existing
FileField, which works fine as long as leave the instantiation the way
it is currently (usi
12 matches
Mail list logo
