Great idea, I'd like to see this implemented too.
Running a memcached instance for small sites seems like overkill.
I'm willing to help write whatever code is necessary.
Silvio
On May 24, 4:21 am, Julien Phalip wrote:
> Hi,
>
> Several people have expressed interest in ticket #12831, which has
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] http://code.djangoproject.com/ticket/
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
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
>
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
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 e
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 thought there was already a ticket open for this, but I can't seem
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: http://code.djangoproject.com/ticket/13643
>
>
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 this message because yo
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 ugly code within the
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 -- there really needs to be
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 django-develop...@googlegr
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 ar
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&ie=UTF-8&q=postgresql+django+slow+count%28*%29#d2d6ca3018f51cb3
I've a table with only 160.000 records (but
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 media.
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 1.0.4 to 1.2.
> > In Django 1.2/1.1 I found that if m
> 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, u
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 t
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 developer
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
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
>> assign new variables on the fly in the template, and
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.
> =
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 possib
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 functions that take argume
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
django-developers+unsubscr..
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 sourc
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 beca
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 exist
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 ve
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
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 th
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" - I
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 go
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 co
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
tem
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 that's really sad)
>
> C
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 wipe
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 please give a concise technical overview, in high-level terms,
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 application factory instead of
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
"
40 matches
Mail list logo