New patch attached : *formset-as_p-as_ul-with-unittests.patch*
*
*
At the moment it is checking the string literal, something I'm a little
opposed to doing. But since it replicates the doctest and all the html seems
to be html5 friendly, so it shouldn't be too much of an issue.
Cheers
On Thu, Aug
Hey Alex,
Thanks for the feedback. I actually had checked this with Russ earlier, but
didn't have a response yet. I prefer TestCases and would be happy to oblige.
I'll move the cases I'm testing to a TestCase in the same file and add the
relevant import to regressiontests/forms/tests.py
D
On Th
On Wed, Aug 4, 2010 at 6:52 PM, David P. Novakovic
wrote:
> Hey, in the interest of easing myself into helping out I've picked an easy
> ticket to get done.
> http://code.djangoproject.com/ticket/12074
> I've fixed the patch and added tests.
> Let me know if I've missed something, or done somethin
Hey, in the interest of easing myself into helping out I've picked an easy
ticket to get done.
http://code.djangoproject.com/ticket/12074
I've fixed the patch and added tests.
Let me know if I've missed something, or done something wrong :)
Cheers,
David
--
You received this message because
On Aug 4, 1:33 pm, Byron wrote:
> What are your thoughts on adding these implementations to core?
I think that the callable key function would fit well in core, and
debatably the flavor, version, and hashing stuff could fit well in
core too. I don't really think that the thundering herd protectio
Hi Eric - I took a look at django-newcache and I like the overall
design. The whole thought behind my patch was a simple way to provide
a global cache prefix since I had ran into key clashes among my
projects (equivalent to your 'FLAVOR' setting). Your solution provides
a much more flexible and ext
Hi Hejsan --
Thanks for the reminder, and for your round-up of the solutions in the
previous thread.
Having used all three of the projects you looked at, and having spent
a bunch of time thinking about the problem, I've come to the
conclusion that nothing's really fully baked enough to consider a
The most flexible way is to be able to specify a callable that runs on
each cache key before it is sent to the server. Then it's just up to
Django to provide a sensible default callable, but people could
override it to provide one which matches their own requirements. This
is what I do in django-
Hi.
As promised I hereby bump this old thread about model translation:
http://groups.google.com/group/django-developers/browse_thread/thread/c6fdd3abea0c7f0e/8cd990e2e1f98e22?lnk=gst&q=hejsan#8cd990e2e1f98e22
I hope there is time to discuss this now even if it will not be
targeted before the 2.0 r
On 8/4/2010 10:57 AM, Jacob Kaplan-Moss wrote:
On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote:
Updated the patch http://code.djangoproject.com/ticket/13795
* Have you considered supporting "versioning" of keys to help with cache
invalidation? Eric Florenzano has been doing some inte
Thanks Jacob. I personally don't think the CACHE_MIDDLEWARE_KEY_PREFIX
is necessary anymore. I suggest removing it, but I would imagine it
would have to be deprecated for the next release then removed in 1.4?
> As a rule, you should avoid evaluating settings at import time, so in
> this case you'd
On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote:
> Updated the patch http://code.djangoproject.com/ticket/13795
Looks good. A couple of questions/comments:
* Is there a reason to keep CACHE_MIDDLEWARE_KEY_PREFIX around? I don't
quite see the point of a separate setting, so unless you can think of
Hi Nowell,
My apologies for the lack of action on this -- I've been really busy
at work over the last month or so. I'm finally coming up for air, and
this ticket is high on my list of things to look at.
The patch itself looks like it's in pretty good shape; I just need to
pick apart the logic to
Updated the patch http://code.djangoproject.com/ticket/13795
On Jun 23, 11:12 am, Russell Keith-Magee
wrote:
> On Sun, Jun 20, 2010 at 6:16 AM, Byron wrote:
> > Yes I agree. I never quite understood why the
> > CACHE_MIDDLEWARE_KEY_PREFIX was implemented, but not at the lower
> > level (did thec
Hey Russ,
Is there anything I should do to get http://code.djangoproject.com/ticket/13922
into RFC state? Let me know if you feel that the existing patch needs
any work, or better docs.
Thanks!
Nowell
On Jul 10, 4:35 am, Russell Keith-Magee
wrote:
> On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite
Sorry this is quite late on this thread, but I hadn't noticed any answer for
it.
How about:
from django import forms
class MyNullBooleanField(forms.NullBooleanField):
def clean(self, value):
if value is None:
raise forms.ValidationError('Choose either Yes or No.')
On Wed, Aug 4, 2010 at 3:27 PM, mrkiwi wrote:
> Hi,
>
> I need to take a template ( written in latex ) and fill it with data,
> then send it through pdflatex to get the pdf output, and return it to
> the user. Django makes this easy, but not quite as smooth as an html
> template.
>
> I use render_
Hi,
I need to take a template ( written in latex ) and fill it with data,
then send it through pdflatex to get the pdf output, and return it to
the user. Django makes this easy, but not quite as smooth as an html
template.
I use render_to_string and output this to a file, then run pdflatex on
tha
Jacob Kaplan-Moss wrote:
> A polite nag on the mailing list -- like this email -- is a perfect
> way to prod things along.
>
Cool, thanks for committing those.
All the best,
Steve.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To pos
19 matches
Mail list logo
