31.12.2012 14:18, Shai Berger kirjoitti:
On Sunday 30 December 2012 21:54:52 Anssi Kääriäinen wrote:
Seems like you are correct [...]. Please open a bug.
For anyone interested that isn't on the new-bugs list, it's
https://code.djangoproject.com/ticket/19542
For anyone else: my apologies for
Thank you, Russ.
I notice that It is exaggerated to change View.dispatch method.
My proposal can be implemented by inheriting View.
With reference to your opinion, I wrote this PredicateProcessView:
https://gist.github.com/4440994
Inheritin this View, We can benefit as well as my proposal.
On Thu, Jan 3, 2013 at 8:17 AM, Florian Apolloner wrote:
> * local_settings is imo a bad pattern as they can't easily override
> anything without copying it completely into the local_settings (think of
> all the settings which are dicts like DATABASES and CACHES)
I use this way to allow variabl
On Thu, Jan 3, 2013 at 1:56 AM, Malcolm Box wrote:
> Hi,
>
> When creating self.client in TestCase, it would be very useful if the
> testcase instance was passed to the client.
>
> I'm using a replacement client class that does various validation checks,
> so wants to use assert* functions on Tes
On Thu, Jan 3, 2013 at 2:46 AM, Hiroki Kiyohara wrote:
> Hi, Russ.
>
> Thanks for your reply.That makes sense.I notice that the configuration of
> my suggestion is complex.
> We need to know what the configuration to take the value.It is necessary
> to re-consider the implementation.
>
> Advantag
On 01/01/13 18:28, Aymeric Augustin wrote:
> There are two special cases that don't fit into apps: STATIC_ROOT and
> MEDIA_ROOT. (Technically, there's ALLOWED_INCLUDE_ROOTS too, but it
> isn't commonly used.)
>
> Static files are collected from the apps into STATIC_ROOT that is
> then served by t
Hi Ted,
On Wednesday, January 2, 2013 10:26:10 PM UTC+1, ted wrote:
> Florian, the method you use for environment specific settings is one of
> the two most common I saw in my survey: local_settings.py being the most
> common. Again, best practice vs common practice I don't know.
>
In my s
To be clear, I'm not proposing the settings.py file from my github as a
django default. It is what works for me, provided for context.
Florian, the method you use for environment specific settings is one of the
two most common I saw in my survey: local_settings.py being the most
common. Agai
Hi,
On Wednesday, January 2, 2013 8:19:36 PM UTC+1, ted wrote:
>
> FWIW, this is a working draft of a default settings file I like that
> addresses most of these issues:
> https://github.com/tedtieken/django-project-skel/blob/master/project_name/settings.py
> (would appreciate constructive cri
> A modern Django project is a collection of apps. Files are looked up under
> conventional paths within apps. Modules (especially the settings module)
> can live anywhere on $PYTHONPATH. Actually, there's not such thing as a
> project root.
>
> For instance, instead of using TEMPLATE_DIRS, p
Hi,
When creating self.client in TestCase, it would be very useful if the
testcase instance was passed to the client.
I'm using a replacement client class that does various validation checks,
so wants to use assert* functions on TestCase, thus takes a testcase
instance as a parameter at creat
Hi, Russ.
Thanks for your reply.That makes sense.I notice that the configuration of
my suggestion is complex.
We need to know what the configuration to take the value.It is necessary to
re-consider the implementation.
Advantage of my approach
-
My approache
Hi Yann,
There's [a thread on django-users][1] that should answer your request.
>From Russ "It's difficult to give an exact date for the release of Django
1.5. We've put out 2 beta releases, which means there are no more features
to be added; and the list of release blocking bugs is down to sin
On Wed, Jan 2, 2013 at 1:36 AM, Victor Hooi wrote:
> Hi,
>
> I may have missed it, but has been a fundamental shift in how Django looks
> at projects versus applications, and how they should be laid out?
>
> I get the impression from Alex Gaynor's comments above that the concept of
> "projects" is
Hi team,
Thanks for amazing job!
But an update about the release date would be really great :)
Thanks
Yann Beaud
Le mardi 11 septembre 2012 16:22:20 UTC+2, Jacob Kaplan-Moss a écrit :
>
> Hi folks --
>
> I wanted to fill everyone in on our plans for the Django 1.5 release.
> The highlights a
+1 on the idea of just adding PROJECT_ROOT official setting and using that
as needed - this is what I do in my projects already.
-Original Message-
From: Luke Plant
Sent: Sunday, December 30, 2012 6:01 PM
To: django-developers@googlegroups.com
Subject: Re: Relative path support for TEM
This mailing list is about the development of Django itself, please direct
user questions to django-users.
Regards,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.co
I am using django 1.5b2 and custom user models.
I have a method in model managers, create_inactive_user(). Activation codes
for users are on a different methods, Activation. I want to have an entry
created in Activation table, to correspond against the inactive user. What
I am using right now i
Hi Hiroki,
Thanks for the suggestion, but I'm afraid I don't see the benefit of doing
this as configuration, rather than something in the dispatched method
itself. Using your gist as an example -- why should this be something
defined in a custom dispatching configuration format, rather than simply
Hello, and Happy new year, everyone.
Please listen to my proposal.
I want django.views.generi.View.dispatch method to call methods in
consideration of some config.
For example, calling methods depending on the value of the request parameter.
So I wrote this commit:
https://github.com/hirokiky/
20 matches
Mail list logo
