On Nov 5, 6:51 pm, Gabriel Hurley wrote:
> 1. Add the versionadded directive to "docs/topics/db/queries.txt", and
> "docs/ref/contrib/contenttypes.txt". For reference, you can make it
> very clear what was changed/added by using the following syntax (note
> the *single* line break between the ve
> Another documentation-related question I have; is it necessary to mark
> each passing referencing (and link) to on_delete with the version-
> added marker? I went back and forth, and eventually decided against
> it, for these reasons: (1) The passing references don't provide enough
> info to use
On Nov 5, 11:17 am, Russell Keith-Magee
wrote:
> Giving credit where it's due, I think Michael Glassford also deserves
> a shoutout here. He was the original driving force behind this ticket,
> as was actively involved during the 1.2 development cycle.
Indeed! My mistake. I'd made a mental note a
I was going to propose the same thing Santiago. Signals seem like the
ideal candidate to solve that problem.
--
David Cramer
http://www.davidcramer.net
On Fri, Nov 5, 2010 at 4:57 AM, Santiago Perez wrote:
>> * Settings that are internally cached. For example, anything that
>> modifies INSTALL
Actually, I've already added your function into my django_future.py ;-)
Thank you!
I wasn't sure it's good with inheritance - good to hear that!
But I wanted to know "the right way" in Django, and since your patch isn't
in trunk yet, I didn't want to rely on it.
If using both mixins and decorators
2010/11/6 Łukasz Rekucki :
> On 5 November 2010 16:52, Valentin Golev wrote:
>> I'm sorry, I misread it.
>> Please mention form.instance field in "forms for models" docs somewhere.
>>
>> The gain is inheritance. If one of your view classes is intented to be
>> subclassed and requires logging in, M
On 5 November 2010 16:52, Valentin Golev wrote:
> I'm sorry, I misread it.
> Please mention form.instance field in "forms for models" docs somewhere.
>
> The gain is inheritance. If one of your view classes is intented to be
> subclassed and requires logging in, Mixins are natural solution, methin
On Thu, 2010-11-04 at 19:06 -0700, SmileyChris wrote:
> Thanks for following up, Luke.
>
> I understand your point of view, but personally, I'm fine with an "all
> bets are off using built-in filters/tags" clause on a custom escape
> method.
> While you'd expect that addslashes would just work, I'
I'm sorry, I misread it.
Please mention form.instance field in "forms for models" docs somewhere.
The gain is inheritance. If one of your view classes is intented to be
subclassed and requires logging in, Mixins are natural solution, methinks
--
Best Regards,
Valentin Golev
Lead Developer
r00, ht
On Fri, Nov 5, 2010 at 11:40 PM, Valentin Golev wrote:
> Are you certain about self.instance?
> http://code.djangoproject.com/browser/django/trunk/django/views/generic/edit.py Lines
> 173 and 90 tell me another thing...
I didn't say self.instance. I said *form*.instance.
> Well, Django can provi
Are you certain about self.instance?
http://code.djangoproject.com/browser/django/trunk/django/views/generic/edit.py
Lines
173 and 90 tell me another thing...
Well, Django can provide tools for extending views with either decorators or
mixins (or both - won't it cause uncertainity? maybe with some
On Fri, Nov 5, 2010 at 10:29 PM, Valentin Golev wrote:
> Hello,
>
> I'm still playing with brand new class-based views. I think I'm not
> wrong about writing my experiences, questions and ideas so you
> developers could polish the API more (if I'm being useless here,
> sorry).
>
> My first questio
On Fri, Nov 5, 2010 at 1:27 PM, Carl Meyer wrote:
> Hi all,
>
> The patch for #7539 [1] (support for on_delete behaviors other than
> cascading deletes) has reached a state where I consider it a candidate
> for committing; I invite review and comments. The current patch is
> available as a github
On Fri, Nov 5, 2010 at 1:27 AM, Carl Meyer wrote:
> Hi all,
>
> The patch for #7539 [1] (support for on_delete behaviors other than
> cascading deletes) has reached a state where I consider it a candidate
> for committing; I invite review and comments. The current patch is
> available as a github
Hello,
I'm still playing with brand new class-based views. I think I'm not
wrong about writing my experiences, questions and ideas so you
developers could polish the API more (if I'm being useless here,
sorry).
My first question is, that is "the right way" to handle creation of
objects with param
Thanks for the explanation and perfect example Luke.
I thought I would try to be helpful and went through the source code
for all the filters and categorised them (see below). There are 12
filters that can't be used (8 are for html only anyway), 24 filters
may fail unpredictably (like your example
>
> * Settings that are internally cached. For example, anything that
> modifies INSTALLED_APPS.
>
> * Settings that need to make call to reset state affected by loading
> new new group of settings. For example, if you change TZ, you need to
> call "time.tzset()" on teardown to reset the timezone
On Nov 5, 2:18 am, Alex Gaynor wrote:
> def setUp(self):
> self.old_SETTING = getattr(settings, "SETING", _missing)
>
> def tearDown(self):
> if self.old_SETTING is _missing:
> del settings.SETTING"
> else:
> settings.SETTING = self.old_SETTING
How about introducing a n
18 matches
Mail list logo
