Re: django template revision (for 1.4?)

We're not changing the template syntax. Full stop. If you don't like Django's syntax, I'm sorry. There are literally dozens of other template languages; I'm sure one will fit anyone's personal needs and style. Jacob -- You received this message because you are subscribed to the Google Groups

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

Hello, On May 26, 4:52 pm, Ivan Sagalaev wrote: > Could you please give a concise technical overview, in high-level terms, > on what twod.wsgi actually does to Django code? Sure. There are different components, so I'll elaborate on them individually: Paste Deploy

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

Sorry, I forgot to link to the embedded application docs: http://packages.python.org/twod.wsgi/manual/embedded-apps.html On May 27, 10:08 am, Gustavo Narea wrote: > Hello, > > On May 26, 4:52 pm, Ivan Sagalaev wrote: > > > Could you

Re: django template revision (for 1.4?)

On Thursday 27 May 2010 03:21:43 Charlie Nolan wrote: > I'm all for streamlining the template system, because I think it's > one of the less-intuitive aspects of Django at the moment (I think > PHP has us beat, and that's really sad) Care to elaborate? From my perspective Django's templates

Re: django template revision (for 1.4?)

On Thu, May 27, 2010 at 12:20 PM, Luke Plant wrote: > On Thursday 27 May 2010 03:21:43 Charlie Nolan wrote: > >> I'm all for streamlining the template system, because I think it's >> one of the less-intuitive aspects of Django at the moment (I think >> PHP has us beat, and

Re: django template revision (for 1.4?)

The inability to assign variables is an intentional design decision; one of Django's core tenets is that business logic and presentational logic should be separated. The template language was crafted to provide non-programmers (front-end developers and designers) the ability to work directly on

Re: django template revision (for 1.4?)

I never claimed it wasn't; it was stipulated that Django's template system wipes the floor with all others, and it is inconceivable to think more favourably of a different system. I was trying to point out that there are features which are available in other template languages, which people may

FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

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 configurable in the admin.py Is the development of the admin interface

Re: django template revision (for 1.4?)

On Thursday 27 May 2010 13:33:10 Tom Evans wrote: > I never claimed it wasn't; it was stipulated that Django's template > system wipes the floor with all others, and it is inconceivable to > think more favourably of a different system. I never said that Django wipes the floor with "all others" -

Re: django template revision (for 1.4?)

My apologies, I did not intend to trigger an offtopic discussion, even a semi-related one. My intent was merely to point out that Django's templating system is far from perfect, and that improving it is definitely a goal of Django, even if we reject a particular change that may appear to be for

Trac version field

I've noticed a lot of people lately updating the trac version field of to be more recent. For example changing version from 1.0 to 1.2 or 1.1 to SVN. I thought this field was supposed to track the version against which a problem was written -- that is, the version of code in use by the reporter of

Re: Trac version field

My interpretation of the "version" field is "the most recent version in which the problem has been confirmed". If a user spots something in an older version, it could be fixed or made irrelevant in SVN, leading to a search for a problem which doesn't exist. By that interpretation, updating the

Re: Trac version field

Charlie Nolan skrev 2010-05-27 16.10: My interpretation of the "version" field is "the most recent version in which the problem has been confirmed". If a user spots something in an older version, it could be fixed or made irrelevant in SVN, leading to a search for a problem which doesn't

Re: DjangoCon.eu sprint proposal: New field type "CompositeField"

Please check out the repacked and slightly refactored implementation of CompositeField: http://bitbucket.org/mp/django-composite-field I'm currently lacking ideas how to get that into admin without having to specify all subfields in the fieldsets. --mp -- You received this message

Static media handling - ticket 12323

A Django 1.3 proposal. It is a pretty small feature/change in some ways, but needs some discussion. = Motivation = This is intended to make it easier to cope with the distinction between user provided media and developer provided media. This is a significant pain point when it comes to

Request: 1.3 proposals include "Proposal" in subject

Would help keeping track of proposals. :-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to

Re: django template revision (for 1.4?)

On Thu, May 27, 2010 at 7:36 AM, Tom Evans wrote: > Most PHP templating languages allow you to do things that are by > design not in django's templating, for example in Smarty, one can > assign new variables on the fly in the template, and even do crazy > stuff like call

Re: Class based generic views in 1.3?

On Thursday 13 May 2010 12:08:26 Luke Plant wrote: > 3) Add the decorators when you call 'instantiator' (which, by the > way, I would rather call 'make_view' or something more specific). > You would then have, *in views.py*: > > 3a) my_view = some_decorator(make_view(MyViewClass)) > > or

Re: Static media handling - ticket 12323

On May 27, 2010, at 9:23 AM, Luke Plant wrote: > A Django 1.3 proposal. It is a pretty small feature/change in some > ways, but needs some discussion. > > = Motivation = > [...] I am on board with the motivation here. The reasons given are exactly why we made a similar change to Pinax. > =

Re: django template revision (for 1.4?)

On Thu, May 27, 2010 at 4:36 PM, Tom X. Tobin wrote: > On Thu, May 27, 2010 at 7:36 AM, Tom Evans wrote: >> Most PHP templating languages allow you to do things that are by >> design not in django's templating, for example in Smarty, one can >>

Simple suggestion (forms and fields with dynamic parameters)

Hi! I have an application where I need a field for selecting between some predefined options that are dynamic up to the point where the form is instantiated. So I've used a TypedChoiceField and overwritten __init__ on the form (not the field) to set the choices based on a database lookup and some

Re: Class based generic views in 1.3?

Hello, We're working on this with Ben during djangocon.eu sprint [1]. Any comment appreciated, still a work in progress though. Regards, David [1] http://github.com/bfirsh/django-class-based-views -- You received this message because you are subscribed to the Google Groups "Django

Re: Static media handling proposal - ticket 12323

On Thursday 27 May 2010 17:09:58 Brian Rosner wrote: > > = Options = > > > > We could: > > 1) add 'STATIC_URL' and use it for widgets and all other media. > > 2) add 'USER_MEDIA_URL' and 'USER_MEDIA_ROOT' and use them for > > file storage. > > I am torn between these two. I am in favor of both

Re: Trac version field

> That doesn't make any sense since a fixed bug would be closed. Not until after time is spent trying to reproduce/understand the bug. If you know when it was last seen, you can confirm that you are triggering it correctly, but that it no longer exists in the current version. >> interpretation,

Re: Django models should not contain 'evaluate' field/method since Django 1.1

Sure, The ticket: http://code.djangoproject.com/ticket/13640#preview Greetings, Lukasz On May 25, 2:49 pm, Jacob Kaplan-Moss wrote: > On Tue, May 25, 2010 at 12:06 PM, naos wrote: > > I was migrating some django project recently from django

Re: Static media handling - ticket 12323

Am 27.05.2010 um 17:23 schrieb Luke Plant: > A Django 1.3 proposal. It is a pretty small feature/change in some > ways, but needs some discussion. > > = Motivation = > > This is intended to make it easier to cope with the distinction > between user provided media and developer provided

Admin sloooow with postgresql and a 160k record table

With postgresql count(*) is a slow operation because it forces a full table scan: http://groups.google.it/group/pgsql.performance/browse_thread/thread/6f94b296019a0e1e/d2d6ca3018f51cb3?hl=it=UTF-8=postgresql+django+slow+count%28*%29#d2d6ca3018f51cb3 I've a table with only 160.000 records (but a

django queryset issue

Hi all, Here is my question details http://stackoverflow.com/questions/2915880/django-objects-all-method-issue this is driving me crazy, after a save(), i can see the new data in mysal db, but i cannot get new data from queryset. Thanks in advance. -- You received this message because you

Re: django queryset issue

Please ask questions related to using Django on django-users. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Admin sloooow with postgresql and a 160k record table

rOn Thu, May 27, 2010 at 10:48 PM, Marcob wrote: > I've a table with only 160.000 records (but a record has many fields) > and opening its admin page takes 55 seconds. A select count(*) takes > 50 seconds, so I know it's all a db problem. Yeah, this is a known problem --

Re: Admin sloooow with postgresql and a 160k record table

On 27 Mag, 23:13, Jacob Kaplan-Moss wrote: > I thought there was already a ticket open for this, but I can't seem > to find one. Can you open a ticket so that we don't forget? Sure. Meanwhile I solved my problem with LazyPaginator and a bit of monkey patching. I'll post my

Re: Admin sloooow with postgresql and a 160k record table

On May 27, 11:13 pm, Jacob Kaplan-Moss wrote: > I thought there was already a ticket open for this, but I can't seem > to find one. Can you open a ticket so that we don't forget? To posterity: http://code.djangoproject.com/ticket/13643 :-) Ciao. Marco. -- You received

Re: Admin sloooow with postgresql and a 160k record table

On Thu, May 27, 2010 at 11:54 PM, Marcob wrote: > On May 27, 11:13 pm, Jacob Kaplan-Moss wrote: > >> I thought there was already a ticket open for this, but I can't seem >> to find one. Can you open a ticket so that we don't forget? > > To posterity:

Re: Admin sloooow with postgresql and a 160k record table

Found via google site:... http://code.djangoproject.com/ticket/8408 On Thu, May 27, 2010 at 4:58 PM, Alex Gaynor wrote: > On Thu, May 27, 2010 at 11:54 PM, Marcob wrote: >> On May 27, 11:13 pm, Jacob Kaplan-Moss wrote: >> >>> I

Re: Class based generic views in 1.3?

On Thursday 27 May 2010 17:29:28 David Larlet wrote: > Hello, > > We're working on this with Ben during djangocon.eu sprint [1]. Any > comment appreciated, still a work in progress though. Looks cool. I think Jari's idea of a class method to instantiate the classes would be a great pattern to

Proposal: modular django configuration

Hi everybody, Everyone loves the way templates are discovered in django. No one loves settings.py that much. This is proposal on how to improve situation significantly. Configuration facility is suggested in addition to django.conf.settings. Configuration is going to be put into conf/ directory

Re: Static media handling - ticket 12323

Hi all, > - a media files path resolver -- following a similar directory structure as > the app templates loader (/media/ vs. /templates/) > - build_static -- a mangement command that'll collect media files from apps > from various locations using the media files path resolver and uses a file

Re: Static media handling - ticket 12323

On May 27, 2010, at 5:27 PM, burc...@gmail.com wrote: > Hi all, > >> - a media files path resolver -- following a similar directory structure as >> the app templates loader (/media/ vs. /templates/) >> - build_static -- a mangement command that'll collect media files from apps >> from various

#11882 Ready for checkin?

I was today momentarily caught out by the missing documentation for formfield_for_manytomany, and found #11882 [1] which has a patch for this very issue and was marked "Ready for checkin" last year. It's a shame it missed 1.2 Anyone care to give it a push? [1]