Not going to weigh in on if this is worth it or not, but if you're
interested and are looking for a way to set up a rendering speed benchmark,
this is the approach that floppyforms took to sanity check their changes:
https://github.com/gregmuellegger/django-floppyforms/blob/master/benchmark.py
One problem with it as you've found is that you sometimes do want control
over it on a per-model or even per-instance (per-save) basis. One way to
deal with this is to create something like the following that you can
extend in your models:
class ValidatedModel(models.Model):
def save(self,
I'm wondering if we can open a quick discussion on the `formfield_callback`
method
of django ModelForms..
The basic issue boils down to the fact that we have an undocumented (and
thus unsupported) method on ModelForm that would benefit greatly from a
small change in behavior and an official bl
I have a concern regarding this.. A few times I have tried to
integrate django-floppyforms which takes a similar approach to what
the html5 widgets offer (input types are specified by default) and it
often causes pain. The reason is that while browsers say they support
html5 input types sometimes t
OK, I opened a new ticket for my issue (http://code.djangoproject.com/
ticket/15574) and reverted the subject on the existing ticket #14642
to the original subject. I uploaded the test case I wrote to the new
issue and I'll look to create a test case for #14642 while I'm at it.
Thanks for the advic
(Sorry Ramiro, I think I replied directly to you instead of to the
group. Resending here)
Understood. I believed I was adding a testcase and expanding the scope
of the issue but it is certainly possible that they are two separate
causes. I will keep that in mind in the future and will certainly op
It seems that I have managed to get a reproducible process for an
issue that has flummoxed a few other people over the past few months:
http://code.djangoproject.com/ticket/14642
In a nutshell, inline formset code (which I have relatively little
understanding of so far) is not protected from simul
Russ, Carl, thanks for your feedback. Russ, I understand what you say
about not wanting to adopt crypto code because of the additional
responsibility. Unfortunately, there aren't very good options. Django
contrib.auth already makes the recommendation of SHA1 which we all
agree is less than ideal. T
Here is an overview of issues on this subject opened over the years.
Some have existing code:
http://code.djangoproject.com/ticket/3316 (Adding `crypt' to list of
password hashes for legacy apps. - closed: fixed)
http://code.djangoproject.com/ticket/5600 (Patch to enhance
cryptography on django.co
There are a lot of ideas and opinions, and a fair amount of confusion
floating around here. Please allow me to summarize the questions and
add my commentary:
1.) Should Django ship using SHA1 (with the current salt length or
even with more bits added)?
- I don't think so. SHA2 (256 or 512) is str
10 matches
Mail list logo
