Re: Feature idea

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

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

On 05/29/2010 01:51 AM, Gustavo Narea wrote: Basically, when you need to integrate a piece of WSGI middleware that must be present both on development and deployment, you have to get rid of `manage runserver' and use a development server like the one from Paste or CherryPy. Middleware that

Re: Project-wide cache prefix (low-level API)

What about the problem that you can, in theory, use the same application several time (several instance) within the same project? I don't have a real use-case, but I have heard people doing it. http://groups.google.com/group/django-users/browse_thread/thread/076f31a1a5479676/8d5f2e0f8f1e1957

Re: Feature idea

On 06/01/2010 09:42 PM, Sean O'Connor wrote: 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. Auto-discovery and

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

On Jun 2, 9:26 am, Reinout van Rees wrote: > On 05/29/2010 01:51 AM, Gustavo Narea wrote: > > Basically, when you need to integrate a piece of WSGI middleware that > > must be present both on development and deployment, you have to get > > rid of `manage runserver' and use a

Re: Project-wide cache prefix (low-level API)

On Jun 2, 9:51 am, batiste wrote: > What about the problem that you can, in theory, use the same > application several time (several instance) within the same project? There is a Google Summer of Code Project http://code.djangoproject.com/wiki/SummerOfCode2010 that

Decision for ticket #6362 - Remove blank spaces with strip when validating the data

Loving v1.2, my first experience with Django: thanks for all the hard work! However this issue has bitten me twice now. I know it is entirely my responsibility to validate and clean user input as required but I really can't think of a valid use case where trailing white space would occur. Also it

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

I second the vote to add the GSoC '09 Admin UI foreign key autocomplete! It's actually somewhat embarrassing that this functionality hasn't made it in yet. Foreign keys in the admin interface become unusable if you have more than 50 or so rows in the table. I hope that since this code has already

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

Current Admin Extensions ForeignKeyAutocompleteAdmin - ForeignKeyAutocompleteAdmin will enable the admin app to show ForeignKey fields with an search input field. The search field is rendered by the ForeignKeySearchInput form widget and uses jQuery to do configureable autocompletion.

Re: Class based generic views in 1.3?

Maybe I've missed the reason, or it's just too late to change, but why not using a class itself (so basically its __init__ method) as a view. I'm using something like this in my projects (as a base class): class View(HttpRequest): def __init__(self, request, *args, **kwargs):

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

On Sun, May 30, 2010 at 2:07 AM, Gustavo Narea wrote: > Hello, > > On May 28, 6:13 pm, Russell Keith-Magee > wrote: >> This is all very helpful information; thanks for breaking it down like this. >> >> I've talked this over with a few people at the

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

If I recall correctly, there's another branch on the that project that was refactoring the autocomplete widgets so that there were essentially 2 widgets: A widget intended to be used in your own Django code, and an admin widget that was a subclass for use in the admin. To me that would be a nice

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

On Wed, Jun 2, 2010 at 11:20 AM, Rob Hudson wrote: > Also, at the time, many of the jQuery autocomplete widgets were in a > state of flux or had some warts.  Our (Jannis and my) idea at the time > was to write our own from scratch, custom and optimized for Django. > That looks to

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

> To me that would be a nice feature addition. It does, however, bring > into question the fact that a widget, intending to be used on the > public side, would depend on jQuery for its UI. Is Django ready to go > there? Or would an admin-only autocomplete widget be preferred? The jQuery based

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

+1 for JqueryUI, it has come a long way in the last year, and it now has a nice system for subclassing widgets with the widget factory. http://bililite.com/blog/extending-jquery-ui-widgets/ -Thomas On Wed, Jun 2, 2010 at 18:45, Jannis Leidel wrote: > > To me that would be a

Re: exception handling memory leak...

On Mon, May 31, 2010 at 4:07 AM, Kevin howerton wrote: > http://code.djangoproject.com/ticket/10758 > > Can we fix this?  It's a pretty easy fix. I really don't want to be a jerk here, but this is precisely the *wrong* way to go about getting work. Reminders are okay,

Re: Feature idea

Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd cover this use case, as well as a whole lot more. There's a few hints in the logging discussion a few threads down. So I'm -1 on this specific proposal, but only because I expect it to be obsoleted by me and Russ' startup

Re: Feature idea

Hi Jacob, I don't know much about the startup proposal, but I expect it to be a startup.py file in an application folder that gets loaded right after the django internals are ready and before the models have been loaded. The mechanism we ask for in this thread is something different. It would be

Re: Feature idea

On Wed, Jun 2, 2010 at 9:28 PM, Gregor Müllegger wrote: > I don't know much about the startup proposal, but I expect it to be a > startup.py file in an application folder that gets loaded right after > the django internals are ready and before the models have been loaded. >

Re: Feature idea

On Wed, Jun 2, 2010 at 3:14 PM, Jacob Kaplan-Moss wrote: > Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd > cover this use case, as well as a whole lot more. There's a few hints > in the logging discussion a few threads down. > > So I'm -1 on this specific

Ticket #10284

Hi, I'd really like to get this ticket resolved, and I'm willing to do the work personally, but I've never contributed before, so I was hoping to solicit some guidance. It seems to me that we'd need a similar patch to the one already existing but updated against trunk and a patch for the

Re: Ticket #10284

Hi, J. Alheid, Don't be too afraid to get started. From looking at the history on that ticket (as well as the current codebase), my guess is that Jacob's concern is that there's no mechanism in place for handling what happens to those objects if commit=False. The current patch tells us what *not*

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

Hello, Russell et al. I am not saying that Django's WSGI implementation doesn't comply with the specification. In fact, I've been talking about improving "WSGI support" not "WSGI compliance". It does comply with the specification, but just internally without exposing all the WSGI-related

Re: Class based generic views in 1.3?

On Wednesday 02 June 2010 16:08:24 Roald wrote: > Maybe I've missed the reason, or it's just too late to change, but > why not using a class itself (so basically its __init__ method) as > a view. I'm using something like this in my projects (as a base > class): > > class View(HttpRequest): >

Re: Class based generic views in 1.3?

On Tuesday 01 June 2010 11:43:30 henning.schroe...@gmail.com wrote: > 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

Re: Class based generic views in 1.3?

On 2 Jun 2010, at 22:31, Luke Plant wrote: > On Tuesday 01 June 2010 11:43:30 henning.schroe...@gmail.com wrote: >> 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

Re: exception handling memory leak...

This was not a "hey you guys are lazy", actually came across it ... after I had fixed the same issue. I just posted a patch for you generated off trunk... and left a hopefully somewhat entertaining explanation of the details surrounding the issues. -k -- You received this message because you

Re: Class based generic views in 1.3?

On Sat, May 29, 2010 at 11:06 PM, Ben Firshman wrote: > Luke, you're absolutely right that changing the definition of a view is a bad > idea, it just seemed the best solution then. > > But don't worry, we've changed our minds again! If __call__() creates a copy > of self

Re: Proposal: Nice(r) error messages when a user-provided module fails to load

On Wed, Jun 2, 2010 at 1:58 AM, Charlie Nolan wrote: > 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 >