Hi Dj Gilcrease,
I've almost implemented kinda similar proposal (draft here:
http://groups.google.com/group/django-developers/browse_thread/thread/b7339d8577567d95
),
and what worries me, is that in current Django you just can't do
autodiscover of django contribs in settings.py because of circula
Yea, I definitely agree that it is a simple solution. I think the the
fact that the setting is optional and would not break any existing
code, it should be included since it "feels" like a common case... we
shall leave it up to the core devs to determine this.
On Jun 1, 7:14 pm, Gabriel Hurley wr
Personally, I solved this by writing a wrapper around
django.utils.cache that can be dropped in transparently. It was a
really simple matter to have it take a cache prefix (in my case from
settings.py) and pass that into the original functions.
It's a pretty easy fix if the core team agrees that i
I would volunteer for the development needed to get this into django.
I will start working on it right after a core developer has looked
into this discussion and points out if my proposal is at least the
right direction.
--
Servus,
Gregor Müllegger
2010/6/1 Dj Gilcrease :
> On Tue, Jun 1, 2010 at
On Tue, Jun 1, 2010 at 3:02 PM, Gregor Müllegger wrote:
> My proposal would go into the direction of pulling the autodiscover
> function out of the django.contrib.admin module and putting it
> somewhere in the core. Since the admin needs some special
> functionality on errors while loading an admi
I've been generally thinking about putting together a package of reusable
tools to implement common "patterns" for reusable apps. Included in this
would be this type of auto-discovery system as well as a registration
pattern. Unfortunately I probably won't get much practical work done on
this too
I like the idea of boxing up the autodiscover code into a publicly
accessible utility class... it's a problem many people solve for
themselves (myself included) but even moreso it would go well with the
new startup.py proposal that's in the works.
Once it's easy to have things run once at startup,
I also needed this functionality in one of my apps and just went the
way of copy and pasting the existing solution that is already
implemented in django.contrib.admin. But making this code reuseable
would IMO be a benefit for some app developers.
But I think the approach of using an setting for th
It was suggested in bug #13480 that I raise this issue "during the 1.3
feature discussion phase", which we seem to have entered.
Essentially, the issue is that a typo in my_app/views.py or any of its
dependencies can raise an error on module import and break the entire
site, leaving the user with
I ran into a seemingly common problem with cache key conflicts between
two projects that both share an app and the same memcache instance. I
would imagine that being able to optionally set a PROJECT_CACHE_PREFIX
that is prepended to every key when setting/getting would be a nice
transparent way of
There are currently several modules / apps that require auto discovery
based on whats listed in INSTALLED_APPS. admin, django_nav, and the
proposed startup.py and I know one or two other apps that use similar
methods but cannot remember their names off the top of my head.
I would like to propose a
On Jun 1, 2:15 pm, Russell Keith-Magee wrote:
> IMHO, that use case would be better handled with two different
> settings files -- one with DEBUG=True and debug logging, and one with
> DEBUG=False and production logging. Having multiple settings files
> isn't an unusual deployment arrangement; th
On Thu, May 27, 2010 at 8:26 PM, Philipp Metzler wrote:
> hello,
>
> i'm looking for exactely the same solution for an "Ajax foreign key
> filter in the Django admin interface" and hoped it would be integrated
> into the admin interface. I think it should be standard behaviour and
> could be confi
On Tue, Jun 1, 2010 at 3:14 PM, Vinay Sajip wrote:
>
> On Jun 1, 3:07 am, Russell Keith-Magee
> wrote:
>>
>> My concern here is YAGNI. Can you suggest a specific use case where
>> this will actually be required?
>
> I agree with the YAGNI principle generally, but to my mind it's
> something to be
On May 30, 7:24 am, Waldemar Kornewald wrote:
> Maybe I missed something, but why don't you use __new__ instead of
> copying the instance?
Here is an example where I used __new__ for class based views in my
project:
http://djangosnippets.org/snippets/2046/
No __call__ or as_view is needed with thi
On Jun 1, 8:29 am, James Bennett wrote:
> There was an issue a few days ago where Media Temple -- which provides
> our hosting -- was under a DDoS attack, and so sites hosted there were
> intermittently available. That's since been resolved.
Right, perhaps that explains it. It's accessible now,
On Tue, Jun 1, 2010 at 2:26 AM, Dougal Matthews wrote:
> It's fine from here (Edinburgh) and I've not had any problems lately.
There was an issue a few days ago where Media Temple -- which provides
our hosting -- was under a DDoS attack, and so sites hosted there were
intermittently available. Th
On 1 June 2010 08:23, Vinay Sajip wrote:
> I've been having trouble accessing www.djangoproject.com recently,
> from here in the UK. Is this a known problem? Is the server down?
>
>
It's fine from here (Edinburgh) and I've not had any problems lately.
Dougal
--
You received this message becaus
http://downforeveryoneorjustme.com/djangoproject.com
On 1 June 2010 17:23, Vinay Sajip wrote:
> I've been having trouble accessing www.djangoproject.com recently,
> from here in the UK. Is this a known problem? Is the server down?
>
> Regards,
>
> Vinay Sajip
>
> --
> You received this message b
I've been having trouble accessing www.djangoproject.com recently,
from here in the UK. Is this a known problem? Is the server down?
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On Jun 1, 3:07 am, Russell Keith-Magee
wrote:
>
> My concern here is YAGNI. Can you suggest a specific use case where
> this will actually be required?
>
I agree with the YAGNI principle generally, but to my mind it's
something to bear in mind if one were implementing a new feature with
a fair a
21 matches
Mail list logo
