Re: "@cache_page" bug...
OK, i accepted: The documentation should not document bugs. This is the job for trac. But on the other side: The documentation should IMHO never have example code that doesn't work. In this specific instance, a remark would have been enough. e.g.: "This example code doesn't work until #1015 is fixed. A work-a-round is to use this code: FooBar..." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: BooleanField and NullBooleanField (#2855 again)
On Jun 25, 3:06 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Consistency in API seems to imply that "null=True" should always works > and permits empty values to be stored. It also means fields without a > default need a value to be set. You make a very good point. However I still think that it at least should be documented, that a BooleanField will not be saved, if not given either a default value or a value. E.g. "BooleanField: A true/ false field. NOTE: Unless null = True, this field requires value.". And I still think it's a bit much letting such a problem get all the way to the db. > I haven't looked at that ticket for a while, but I'm inclined to say > it's not a bug. What ever it is, my life would have been 30 minutes easier if it were documented, or transparent. -- Mads Sulau Joergensen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Inline editing without a parent model
On 6/24/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > On 6/24/07, Tomi Pievil�inen <[EMAIL PROTECTED]> wrote: > > > > Will there be a possibility to use edit_inline with a model that > > doesn't have a parent model in newforms admin? It would be really > > useful to see other lines when you need to input relatively same data > > (and I was planning to hack some kind of copy&paste functionality in). > > If this is not going to happen, I'll just start making my own (with > > formsets, I suppose) but I'd prefer to avoid duplication. > > I don't think something like that would go into the admin system > anytime soon. That said though, doing it yourself should be *much* > less painful with newforms-admin using formset_for_model and/or > BaseModelFormSet from django.newforms.models. Beware though, the api > still isn't completely stable. it is possible, see http://code.djangoproject.com/ticket/4667 for information on how this can be done... > > Joseph > > > > -- Honza Kr�l E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: "@cache_page" bug...
In this regard, I agree with Jedie. The documentation should really never show non-working examples. Aidas Bendoraitis aka Archatas On 6/25/07, jedie <[EMAIL PROTECTED]> wrote: > > OK, i accepted: The documentation should not document bugs. This is > the job for trac. > But on the other side: The documentation should IMHO never have > example code that doesn't work. > In this specific instance, a remark would have been enough. e.g.: > "This example code doesn't work until #1015 is fixed. A work-a-round > is to use this code: FooBar..." > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Week in Review -- ATTN: Adrian Holovaty
On 6/24/07, Clint Ecker <[EMAIL PROTECTED]> wrote: > > Let me know what you guys think of the tone, my wordiness, how I split up > the post into "random weblinks," changeset roundup, and SoC stuff, and > anything else that comes to mind. Hi Clint, The only correction/addition I have is that's Paul Collier's GSoC project isn't included. [0] Other than that, this your piece very well done. It's great to have "the roundup" back. Thanks for your contribution, - Ben [0] http://groups.google.com/group/django-developers/browse_thread/thread/527c44781ee071f0/76751ba96c9deb2b --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC: packaging Django applications
Thanks Neil, > I would suggest rather saving the information into a file like > release.py, and using execfile in setup.py to read the information. > (Also, it should be easier for you to read the config back in again.) This is a rather good idea which I implemented here at the new django- package project: http://code.google.com/p/django-package/ For now the patch adds a command line switch to the startapp command of django.core.management: # django-admin.py --package startapp myapp which asks for the meta information required for packaging. Please try it out! It creates a basic skeleton application in the current directory, ready to be used by setuptools. For testing purposes you can use setuptools standard functions like running "python setup.py develop" to add it to the python path, uninstalling with "python setup.py develop --uninstall" or wrapping it in an egg file with "python setup.py bdist_egg". Concerning the application skeleton: I would like to collect some of your ideas about the common file names and directories which should be created by default. This is also needed when it comes to packaging non-python files like template html-files, sql-files and so on. What are the common filenames? How do you manage your django projects? As suggested by Neil there is already a release.py for easier manipulation of the meta data. The current code creates this: # ls MANIFEST.in docs/ release.py setup.py test/ myapp myapp/templates/ When introducing something like package management we also have to think about changing the workflow. Current workflow: 1. startproject 2. startapp 3. development and testing 4. semi-automatic deployment Proposed workflow: 1. startapp (with package skeleton and meta information) 2. develop application and test with "python setup.py develop" 3. egg deployment [1] with "python setup.py bdist_egg" and "easy_install myapp-0.1.egg" Generic applications like django-registration, django-tagging, django- voting, django-utils, django-contact-form, django-forum.. [2] can be installed system wide and therefore live on the python path (in python's standard site-packages directory). I'd like to encourage new developers to follow my workflow proposal as it makes development, packaging and deployment much easier. Hence I suggest making it the default behaviour of "startapp" to create standalone packages, while requiring a command-line switch to create an application without the skeleton files (the current "develop inside a project" style, like in the tutorials). One hypothetic idea is to introduce a whole new management command "package" to wrap most of the current functions like "startproject", "startapp" and the ideas before. This would wrap some of setuptools functions and could have a feature-set like: "package project", "package app", "package egg", "package upload" and so on. I actually do think this is evil since it wraps functions of setuptools but your mileage may vary. Tell me what you think! Best, Jannis 1: http://peak.telecommunity.com/DevCenter/PythonEggs 2: http://code.google.com/hosting/search?q=django --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Spam attack on the Django site
Looking at http://www.djangoproject.com/comments/ there seems to be *a lot* of spam. Maybe you should try ubernostrums django-comment-utils (http://code.google.com/p/django-comment-utils/) -- Petar Marić *e-mail: [EMAIL PROTECTED] *mobile: +381 (64) 6122467 *icq: 224720322 *jabber: [EMAIL PROTECTED] *web: http://www.petarmaric.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Week in Review -- ATTN: Adrian Holovaty
Hi, Just a quick note, on: [...] [5502] -- Stefane Femgier submitted a patch that correctly sets the mime-type for admin media content, and was integrated into the trunk the week. [...] Maybe it should read "into trunk this week" not sure about the "the trunk" but "the week" doesn't make sense (although English isn't my primary language ;) Cheers, Marc El dom, 24-06-2007 a las 21:21 -0500, Clint Ecker escribi�: > Hey everyone. I've got a draft prepared of my first Django Week In > Review for tomorrow. I know that it's extremely long compared to > previous WIRs, but I'm trying to catch up for about 2 month's worth > here ;) > > > I've not been able to get in contact with Adrian this past week to > arrange for posting access on the site, so I hope that perhaps he'll > see this (or someone else who can help me) and get ahold of me > off-list. > > > Here's my draft: http://clintecker.com/django-wir-06252007.html > > > Let me know what you guys think of the tone, my wordiness, how I split > up the post into "random weblinks," changeset roundup, and SoC stuff, > and anything else that comes to mind. Again, please keep in mind that > this sort of length probably won't be typical. > > > Clint > > -- > Clint Ecker > Sr. Web Developer - Stone Ward Chicago > p: 312.464.1443 > c: 312.863.9323 > --- > twitter: clint > skype: clintology > AIM: idiosyncrasyFG > Gtalk: [EMAIL PROTECTED] > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Week in Review -- ATTN: Adrian Holovaty
Ah, I think I had meant: "integrated into the trunk this week" Thanks for the catch! Clint On 6/25/07, Marc Fargas <[EMAIL PROTECTED]> wrote: > > Hi, > Just a quick note, on: > [...] > [5502] -- Stefane Femgier submitted a patch that correctly sets the > mime-type for admin media content, and was integrated into the trunk the > week. > [...] > > Maybe it should read "into trunk this week" not sure about the "the > trunk" but "the week" doesn't make sense (although English isn't my > primary language ;) > > Cheers, > Marc > > El dom, 24-06-2007 a las 21:21 -0500, Clint Ecker escribi�: > > Hey everyone. I've got a draft prepared of my first Django Week In > > Review for tomorrow. I know that it's extremely long compared to > > previous WIRs, but I'm trying to catch up for about 2 month's worth > > here ;) > > > > > > I've not been able to get in contact with Adrian this past week to > > arrange for posting access on the site, so I hope that perhaps he'll > > see this (or someone else who can help me) and get ahold of me > > off-list. > > > > > > Here's my draft: http://clintecker.com/django-wir-06252007.html > > > > > > Let me know what you guys think of the tone, my wordiness, how I split > > up the post into "random weblinks," changeset roundup, and SoC stuff, > > and anything else that comes to mind. Again, please keep in mind that > > this sort of length probably won't be typical. > > > > > > Clint > > > > -- > > Clint Ecker > > Sr. Web Developer - Stone Ward Chicago > > p: 312.464.1443 > > c: 312.863.9323 > > --- > > twitter: clint > > skype: clintology > > AIM: idiosyncrasyFG > > Gtalk: [EMAIL PROTECTED] > > > > > > > > > > -- Clint Ecker Sr. Web Developer - Stone Ward Chicago p: 312.464.1443 c: 312.863.9323 --- twitter: clint skype: clintology AIM: idiosyncrasyFG Gtalk: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Week in Review -- ATTN: Adrian Holovaty
On 6/25/07, Clint Ecker <[EMAIL PROTECTED]> wrote: > Ah, I think I had meant: "integrated into the trunk this week" FWIW, both Jacob and Adrian are on trips this week. I'm not sure who else could grant you blog posting permission. I'm sure they'll respond as soon as they can. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Week in Review -- ATTN: Adrian Holovaty
On 6/25/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > FWIW, both Jacob and Adrian are on trips this week. I'm not sure who > else could grant you blog posting permission. > > I'm sure they'll respond as soon as they can. Sorry, I've been offline for the past couple of days. Clint, I'll e-mail you offlist to set things up. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Ticket #650 - render_to_response uses Context instead DjangoContext
Hi all, Just coming back to Django after an 18 month absense, great to see some of the work that's gone on here, i'm really impressed! Been using Rails for a while (not by choice) and it's a joy to get back into Django. Enough of the fluffing though, and down to business. render_to_response is a great shortcut, however in my opinion it's let down by not supporting request. I see this has been discussed a bit on the ticket, however that's more in respect to replacing the existing shortcut. I propose a new shortcut of the following form: Index: django/shortcuts/__init__.py === --- django/shortcuts/__init__.py(revision 5526) +++ django/shortcuts/__init__.py(working copy) @@ -5,11 +5,16 @@ from django.template import loader from django.http import HttpResponse, Http404 from django.db.models.manager import Manager +from django.template.context import RequestContext def render_to_response(*args, **kwargs): return HttpResponse(loader.render_to_string(*args, **kwargs)) load_and_render = render_to_response # For backwards compatibility. +def render_to_response_with_req(request, *args, **kwargs): +kwargs['context_instance'] = RequestContext(request) +return render_to_response(*args, **kwargs) + def get_object_or_404(klass, *args, **kwargs): if isinstance(klass, Manager): manager = klass def get_object_or_404(klass, *args, **kwargs): if isinstance(klass, Manager): manager = klass If anyone has any ideas for better names, please chip in. Regards, Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #650 - render_to_response uses Context instead RequestContext
On Jun 26, 10:45 am, Paul Bowsher <[EMAIL PROTECTED]> wrote: > Hi all, > > Been using > Rails for a while (not by choice) and it's a joy to get back into > Django. Welcome back ;) > render_to_response is a great shortcut, however in my opinion it's let > down by not supporting request. render_to_response(context_instance=RequestContext(request)) Convoluted, and it means having to import RequestContext, but it is possible. I agree, an official shortcut would be good. This comes up at least daily on IRC, with the usual response being http://www.djangosnippets.org/snippets/3/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 - Object-Level Caching
Getting back into the swing of things...
Paul Collier wrote:
>> If I update o1 in some other part of the
>> code, what assumptions are made about qs?
> Hmm, yeah... I haven't focused enough attention on .cache_set() yet,
> heheh. I was definitely just going to implement (1) first, and then
> worry about something more advanced once I got to the "smart"
> functionality (which I might just be making default behaviour now). At
> some point I'll be writing a class with which cached queries register
> so that pre/post_save signals can freshen the cache; that's should
> lightweight enough to scale by itself, but to implement (3) I guess
> it'd also have to track which PKs are present. I'm not really sure if
> (2) is desirable.
I could see how (2) would be desirable if you are expecting
qs.cache_set() to work like cache.set('myqs', qs), which is how I
interpreted your proposal. Though, I could also understand someone
wanting one of the other implementations too.
So what were your implementation thoughts about cache_set()? It appears
that you did not mean for it to simply be a shortcut for doing
cache.set('my_qs', qs). Could you please clarify this?
As far as cache correctness and the pre_save/post_save signals for
refreshing/invalidating the cache, there is sill the possibility of
objects in the database getting altered outside of the currently-running
django instance. In this case, your cache won't be correct, even with
going through all the trouble of trying to keep it updated. This is
where I think option (2) is the desired choice again, for simplicity and
explicitness. Objects are cached until they timeout or until I
explicitly refresh them. Thoughts?
Also, all this object caching seems to me like something that would tie
in nicely to the models themselves. Maybe something similar to the
ModelAdmin class of newforms-admin. Cache refreshing/invalidating
behavior could even be an option if it is implemented.
class Author:
name = CharField()
class AuthorCacheOptions(cache.ModelOptions):
# Cache Author objects?
cache = True
# How long to cache Author objects?
seconds = 3600
# Try to keep cached objects in sync with database?
# If False, cached objects are not updated until they expire.
sync = True
Now, Author query sets using .cache() would use the AuthorCacheOptions
by default when no parameters are passed.
Gary
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
