Re: Feature like "acts_as" in Django ORM or contrib ?
On Tue, Oct 21, 2008 at 12:45 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > In Elixir, when I add acts_as_list(qualifier=qualify) in Model I can > use move_higher, move_lower ... methods. Be careful about confusing multiple things here; there are applications available for Django which add features like this -- objects which behave like hierarchical lists/trees, taggable objects, etc. -- and if you like those features you should certainly go look them up. But those applications do not implement those features with precisely the same names or syntax as ActiveRecord (or Elixir, which deliberately borrows many such conventions from ActiveRecord). Which is a perfectly good thing; Django isn't Rails, isn't written in the same language and consciously tries to be idiomatic Python rather than idiomatic Ruby, so trying to simply apply a a feature from Rails using precisely the syntax Rails uses would cause it to stick out like a sore thumb in Django. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: from mysite.polls.models import Poll, Choice
On Thu, Oct 23, 2008 at 1:47 PM, bruno desthuilliers <[EMAIL PROTECTED]> wrote: > It's indeed a pretty bad idea to refer to the project name in import > statements (as well as in a couple other places too FWIW), and I > defnitively fail to understand why it's documented that way. It's documented that way because it means we can have a tutorial that doesn't immediately dump import-path configuration issues onto people who are brand-new to Python; doing things the way the tutorial does them, everything automatically ends up on the Python path thanks to manage.py. This means, of course, that there is a need for followup documentation which explains that this isn't always the best way to develop real-world apps (in just the same way as the tutorial shows several "wrong" ways to do things like template rendering, etc., before showing the "right" way). Any volunteers to write it? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
ANN: Initial release timelines for Django 1.0.1 and Django 1.1
(putting on release manager hat...) We've just put up an entry over at the official Django project blog with details of the timelines for Django 1.0.1 and Django 1.1: http://www.djangoproject.com/weblog/2008/oct/24/upcoming-releases/ Please bear in mind the immediate consequences of these timelines: * Django 1.0.1 will release November 14, which means that any 1.0 bugfixes you'd like to see make it in will need to have patches and tests prior to that date. * If you have a feature proposal for Django 1.1 that you haven't already brought up on the django-developers list, you'll want to do so quickly; the window for feature proposals will close on November 15. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Django Equivalent to Rails Rumble
On Sat, Oct 25, 2008 at 10:45 AM, Keyton Weissinger <[EMAIL PROTECTED]> wrote: > Is there an equivalent to the Rails Rumble for the Django community? > Shouldn't there be one? What do you think? There was one a couple months ago: http://djangodash.com/ Google is your friend :) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Receiving emails via app
On Sat, Oct 25, 2008 at 2:09 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote: > We have an alias set up in postfix that sends the e-mail to our script > via a pipe. > > The python script imports our Django models, and parses the e-mail > message with the email module, and does what it needs to. You can also use Python's built-in SMTP server module to set up a lightweight server process, and have your regular MTA forward messages to it. This lets the entire mail-processing routine happen in Python, which is often a bit easier to set up. See Doug Hellmann's recent PyMOTW article on this for some basic details: http://blog.doughellmann.com/2008/10/pymotw-smtpd.html -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: database API from external tools?
On Sun, Oct 26, 2008 at 9:19 PM, Steve Holden <[EMAIL PROTECTED]> wrote: > Here's a specific example of a piece of code that uses a web app's > models. It should get you started - just dive in and write some code! > The tricky bit is providing the settings without using a "settings" > module. I can't remember who I got this code from, but the kudos belongs > to them, not me. Enjoy. I'm late to the party on this, but here's my writeup from last year (IIRC all this stuff is in the official docs, too): http://www.b-list.org/weblog/2007/sep/22/standalone-django-scripts/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Easiest way to pass django documentation from rest to HTML?
On Mon, Oct 27, 2008 at 9:27 PM, Mr. Z <[EMAIL PROTECTED]> wrote: > Which is the easiest way to pass the new django documentation from > rest to HTML? This is covered in the documentation: http://docs.djangoproject.com/en/dev/internals/documentation/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Easiest way to pass django documentation from rest to HTML?
On Wed, Oct 29, 2008 at 5:59 AM, Mr. Z <[EMAIL PROTECTED]> wrote: > Thank you both. I'm trying to create a view that converts the ReST > documentation to HTML and shows it integrated with my templates, but > with docutils it gives out a lot of errors. And with sphinx it just > generates plain complete html files with links beteween them :( > > How could I do it? You probably want to read up on Sphinx to learn how to control its behavior, but keep in mind that it's probably not going to be a "press this button and it magically works" thing; most likely, it will be a "learn a bit about Sphinx and write some templates and configuration on your own" thing. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: changing the Manager the admin-site should use
On Thu, Oct 30, 2008 at 7:31 AM, Dennis Schmidt <[EMAIL PROTECTED]> wrote: > Well that does work, though in the Manager documentation it's said: > > "If you use custom Manager objects, take note that the first Manager > Django encounters (in the order in which they're defined in the model) > has a special status. Django interprets this first Manager defined in > a class as the "default" Manager, and several parts of Django (though > not the admin application) will use that Manager exclusively for that > model." This is actually incorrect (open a ticket as a reminder and I'll fix the docs); by default, the admin now uses the default manager for the model, same as everything else in Django. As to your original question, ModelAdmin has a method named 'queryset()', which is used to obtain the QuerySet of objects for display in the admin lists and for looking up objects to edit. Overriding that method on your ModelAdmin subclass is the correct way to do this. This method receives the incoming HTTP request as an argument, so you can use it to filter based on some attribute of the request (e.g., the logged-in user). This also means that when overriding, you must define the method as "def queryset(self, request)", not just "def queryset(self)". -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Using settings.py mechanism for application settings
On Fri, Oct 31, 2008 at 8:29 PM, pk <[EMAIL PROTECTED]> wrote: > Am I missing something? Should that mechanism be refactored so that it > can be used for user applications? Is there a better way to do > application level configuration -- i.e. for app designed to be > distributed and reused? If you look in django.contrib, there are several applications which instruct you to fill in a setting which exists only for purposes of that application. And those are applications like any other application; it's perfectly acceptable for any application to do this, so long as its documentation clearly indicates which settings to supply and what values those settings can have. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Python package names
On Mon, Nov 3, 2008 at 6:23 AM, Dj Gilcrease <[EMAIL PROTECTED]> wrote: > Cause I actually like having the django_apps namespace so I can > quickly identify if something being imported is a django app or some > regular python module A Django application *is* a Python module. It's not some secret special format separate from normal Python modules, it's just a Python module. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Using settings.py mechanism for application settings
On Mon, Nov 3, 2008 at 7:01 PM, pk <[EMAIL PROTECTED]> wrote: > James is right that for any of my own app, I can just tell the user > to put in some settings in the project level settings.py file. In fact > that is exactly what I do now. And that is what quite a number of popular third-party Django applications -- every one of them intended to be used and reused -- are doing. I don't really see a need for some system of forcing default values, since in many cases *not* supplying an explicit value for such a setting is an error (because not supplying it *or* falling back to a default can break the application or cause undesired behavior). Much better to simply document what's needed, and rely on the fact that trying to run without setting it will raise an error. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: django admin - list filter - issues with model fields having name ending in 'y'
On Wed, Nov 5, 2008 at 11:31 PM, ammo <[EMAIL PROTECTED]> wrote: > Does this thing work for anyone else? Well, it works fine for me when I use "verbose_name_plural", which is the correct value and what's listed in the documentation (not "verbose_plural_name" as you've typed here). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: post data and @login_required
On Thu, Nov 6, 2008 at 5:12 AM, coan <[EMAIL PROTECTED]> wrote: > Why isn't there an option to have the request object passed to the > login form? The login view in the Django admin actually used to do this; see our most recent security-oriented release for the reasons why it doesn't do that anymore... -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Installation of django in user account
On Wed, Nov 5, 2008 at 12:18 PM, Tim O'Toole <[EMAIL PROTECTED]> wrote: > But I obviously cant do the following without root access > > ln -s `pwd`/django-trunk/django SITE-PACKAGES-DIR/django > > Whilst I can set the PYTHONPATH, I can't then write to PythonPath in > the Apache configuration file. You may want to try out a deployment option other than Apache/mod_python, then, but I'm honestly a bit curious how you're planning to use mod_python at all if you don't have access to the Apache configuration file. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: How do I display a template with Chinese characters in it?
On Sun, Nov 9, 2008 at 10:13 PM, Frank <[EMAIL PROTECTED]> wrote: > The charset I use in the html file is 'gb2312'. > > What do I have to do in order to be able to display Chinese language > content? You probably want to have a look at the settings documentation: http://docs.djangoproject.com/en/dev/ref/settings/#file-charset -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: A template proposal
On Fri, Nov 14, 2008 at 3:56 PM, ek_wals <[EMAIL PROTECTED]> wrote: > It seems to me that this kind of thing is easily translated to Django > templates, > quicker to type, easier to read, and infinitely extendable. > > Any thoughts before I begin playing? Feel free to write it. I wouldn't get any hopes up for it becoming part of Django, though, since HTML and CSS are kind of fundamental to web design and development, and people should be able to write them (see also: why Django doesn't bundle or offer built-in integration with a JavaScript toolkit). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: How can we improve performance in the Admin when loading profile pages with ManyToMany fields?
On Fri, Nov 14, 2008 at 5:49 PM, Eric Chamberlain <[EMAIL PROTECTED]> wrote: > We have five or so ManyToMany fields (with 10,000+ and growing total > entires in each field, only a few are selected for any one profile) in > our user profile. When we bring up the profile in the admin, the page > takes a while to load and render and taxes django and the database > more than we would like as admin loads all the field possibilities. Try reading the admin docs, specifically for raw_id fields. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
ANN: Django 1.0.1 released
Tonight we've released Django 1.0.1, a bugfix release in the 1.0 series containing improvements and fixes since the 1.0 release. This is a recommended upgrade for anyone currently running Django 1.0. The blog entry announcing the release is here: http://www.djangoproject.com/weblog/2008/nov/15/101/ And the release notes are here: http://docs.djangoproject.com/en/dev/releases/1.0.1/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: ANN: Django 1.0.1 released
On Sat, Nov 15, 2008 at 7:37 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Yep, looks like something went wrong there. James is offline at the > moment, but he'll fix it when he gets a chance. The security-aware user > will avoid using the tarballs until they're fixed. I'm looking into it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: ANN: Django 1.0.1 released
On Sat, Nov 15, 2008 at 7:48 AM, leonel <[EMAIL PROTECTED]> wrote: > Ive downloaded the tar.gz from > http://www.djangoproject.com/download/1.0.1/tarball/ > > and the md5sum does not match the md5sum from: > http://media.djangoproject.com/pgp/Django-1.0.1-final.checksum.txt OK, so here's what happened: 1. When I rolled the release last night, I did 'python manage.py sdist' to generate the package, then uploaded it to the djangoproject.com server. 2. I then made my fatal error, which was that I uploaded it to the Cheese Shop via 'python setup.py sdist upload'. 3. And then I did the checksums and placed the signed file on djangoproject.com. Astute readers will notice what I did not, namely that step 2 re-generated the package, resulting in a tarball whose constituent files and directories have slightly different creation times than the package from step 1. And as a result, the checksums of the package generated in step 2 are different from the checksums of the package generated in step 1 -- even though their unpacked contents are identical -- because 'tar' stores information about creation time in the resulting compressed file. So I've replaced the package on djangoproject.com with the copy generated in step 2 above, and we've verified that its contents and its checksums match exactly. Your friendly local release manager apologizes for the inconvenience, and will now go find someplace to hang his head in shame. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: ANN: Django 1.0.1 released
On Sat, Nov 15, 2008 at 8:42 PM, James Bennett <[EMAIL PROTECTED]> wrote: > 1. When I rolled the release last night, I did 'python manage.py > sdist' to generate the package, then uploaded it to the > djangoproject.com server. (and obviously I meant 'setup.py sdist') -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Django - Python 3
On Sun, Nov 16, 2008 at 8:10 PM, Leonel Nunez <[EMAIL PROTECTED]> wrote: > Will there be many changes for django with python 3 As this is a fairly common question, *please* consider searching the list archives for information. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Built-in Reference - docutils
On Mon, Nov 17, 2008 at 10:26 PM, Horus Kol <[EMAIL PROTECTED]> wrote: > TemplateDoesNotExist at /admin/doc/ > > Anyone got any ideas? It helps to have the admin docs application (which is *not* 'django.contrib.admin', but rather 'django.contrib.admindocs') in your INSTALLED_APPS, so that its bundled templates will be picked up. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
ANN: Django 1.0.2 released
Tonight, to clear up some problems with the packaging of the Django 1.0.1 release from Friday, we've released Django 1.0.2; once again, this is a bugfix-only release, and is a recommended upgrade for anyone targeting or using Django 1.0 or Django 1.0.1. Weblog entry announcing the release is here: http://www.djangoproject.com/weblog/2008/nov/18/102/ Release notes are here: http://docs.djangoproject.com/en/dev/releases/1.0.2/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Keeping fields out of the Admin
On Thu, Nov 20, 2008 at 2:02 PM, Epinephrine <[EMAIL PROTECTED]> wrote: > How can I keep the field from being editable in the Admin edit page > for that class? I don't really mean to sound rude in saying this, but your best bet is probably to read through the documentation for the admin: http://docs.djangoproject.com/en/dev/ref/contrib/admin/ It contains a full reference for the various options you'd most likely want to use in your admin declarations, and is a great source for being able to find information immediately rather than wait around for someone on a mailing list to answer your question. It also contains the answer to the question you've asked. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Novice has doubt!
On Thu, Nov 27, 2008 at 8:12 PM, boloris <[EMAIL PROTECTED]> wrote: > Can you help-me? The error tells you that some edit you have made to your settings file caused it to no longer be a valid Python source-code file. Your best bet is to perhaps try out a Python tutorial to learn the Python programming language (since Django is simply a set of libraries to help you write Python code). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Django abstract base class and table structure
On Thu, Nov 27, 2008 at 5:11 PM, Chris Smith <[EMAIL PROTECTED]> wrote: > From experience with other ORM platforms (nHibernate, custom built), > I'd expect this to flatten out to a table with approximately the > structure: You probably want to read the official Django documentation on how model inheritance works; there is no system under which Django will do STI. Abstract models never create their own tables for any reason; only their child models get tables, and then they get one table per child model. Non-abstract models do multi-table inheritance. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Get values of HTML Select Multiple Tag From request.POST
On Sat, Nov 29, 2008 at 3:19 AM, jai_python <[EMAIL PROTECTED]> wrote: > Issue that I found out is "The variable 'colour' gets overwritten > everytime when the user selects different values". Then how come it is > possible that the request.POST shows all selected values. And why am > not getting the same when i extract value from the variable 'colour'. > Any help would be thankful A full and complete explanation is available in the Django documentation on HttpRequest objects. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Admin - Auto Generate user_id on save
On Sat, Nov 29, 2008 at 5:25 PM, AJ <[EMAIL PROTECTED]> wrote: > to the vairables self and commit. So as far as I can tell I can't do > this in the Admin. It looks like I would need to write my own custom > form and view. Is this correct, or is there another way to do this? Consult the documentation for the admin; there are methods on ModelAdmin you can override to customize and control what happens during object saving. And in general, please consider doing some searching when you encounter something you don't quite know how to do; this is, for example, one of the most-frequently-asked questions about the admin, and the techniques for solving it have been covered repeatedly on this list and elsewhere. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Does Django have a function that can be called by every view function ?
On Sun, Nov 30, 2008 at 11:48 PM, David Shieh <[EMAIL PROTECTED]> wrote: > I think your solution can resolve my problem.But does it a bit > complex ? > In fact , what I really want is a view function that will be called by > every view function. > i.e. , if I wrote an auth system , I need to authenticate whether the > user is logged in every view functions and pass some parameters to > every views function . Perhaps it would be a good idea at this point to read Django's middleware documentation, to get a feel for how that works and how you might put it to use? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: typo in the Django book
On Mon, Dec 1, 2008 at 3:05 PM, coldlight <[EMAIL PROTECTED]> wrote: > Another one: in the file Please don't do this; this is not the errata mailing list for "The Definitive Guide to Django", it is the mailing list for discussion of and by users of Django, and every time you post a message here you are putting something into nearly *12,000* people's inboxes. If you look at the online version of the book you'll see that it's possible to click in the left-hand side of any paragraph to pop open a window wherein you can leave comments; that's likely the best place to put them. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Question from django beginner
On Tue, Dec 2, 2008 at 3:42 AM, Vince <[EMAIL PROTECTED]> wrote: > 2. Is there any built-in opton in Django (0.97 version) to unzip There is no such thing as "Django 0.97". Releases of Django are as follows: 0.90 0.91 0.95 0.96 1.0 (with minor bugfix releases on several of them, like "0.96.1" and "1.0.2") -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Adjusting PYTHONPATH for reusable django apps
For what it's worth, I'm a huge fan of virtualenv: http://pypi.python.org/pypi/virtualenv and of Doug Hellmann's virtualenvwrapper: http://www.doughellmann.com/projects/virtualenvwrapper/ What virtualenv does, basically, is create an isolated Python environment into which you can install stuff without affecting any other Python software on your system. And virtualenvwrapper provides tools for easily creating, removing and working with virtualenvs. So my workflow these days goes something like this: mkvirtualenv somepythonproject (this creates a new virtualenv, named "somepythonproject", and drops me into it; if I come back later in another shell, "workon somepythonproject" will put me back in the virtualenv) >From there I have easy_install for installing Python packages I want to try out, or I can use the "add2virtualenv" function in virtualenvwrapper to add a directory to the virtualenv's Python path. For example: add2virtualenv ~/dev/my-django-apps/ Within the virtualenv, everything I've installed or added to it is available, but it doesn't affect anything else on my system; I can blow it away with no repercussions if I mess something up, or keep adding/tweaking stuff as needed. It's even getting easier to do real deployment with this, too; mod_wsgi supports a directive that lets you point it at a virtualenv to run a site out of a completely-sandboxed environment, so you can simply use normal tools within the virtualenv to set things up and not worry about clashing with anything else. If you haven't looked into this, I highly recommend it. And maybe in the 2nd edition of the book I'll try to explain this a bit more clearly... -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Webservers, Django thread-safeness, etc.
On Wed, Dec 3, 2008 at 11:45 AM, SteveB <[EMAIL PROTECTED]> wrote: > I've had positive experiences with the standalone CherryPy webserver > Although I can't prove it, I'm suspicious that the problem may be that > Django is not thread safe. Can anyone state for a fact that it is > safe to use Django with a multi-threaded webserver? If not, then multi- > threaded webservers like the CherryPy server are not really candidates > for use with Django. No-one can state this for a fact because, even though many people (and this is where I remind everyone that it's often a good idea to search the archives before posting, especially for frequently-asked questions like this one) use Django with thread- as opposed to process-based server solutions without reporting thread-safety issues, it's simply impossible to state, unequivocally, that "everything you will ever do involving Django will be 100% thread safe". This should, incidentally, be fairly clear from the fact that Django offers you numerous ways to work with, e.g., mutable stateful objects, such that Django itself doesn't do anything unsafe with them, but you (and by implication, your code) quite easily can if you're not careful. In other words, the answer is "to the best of anyone's knowledge, Django does not have issues running in threaded servers, and if/when bugs are found which contradict that we fix them". But there isn't and never will be a categorical assurance that Django is provably 100% threadsafe or that there won't from time to time be a bug that needs to be fixed. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Python 3.0 released - what's the status of Django vs. 3.0?
On Thu, Dec 4, 2008 at 1:37 PM, ohmi <[EMAIL PROTECTED]> wrote: > As the subject says - will Django compile and run on Python 3.0? No, nor is it expected to for at least a year or two, something entirely consistent with the general plan for pretty much all Python software to migrate. If you're genuinely interested in more, **please** search the archives of this list for the many times this question has been asked and answered before. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Invalid block tag: render_comment_form (repost)
On Fri, Dec 5, 2008 at 2:07 AM, Florian Lindner <[EMAIL PROTECTED]> wrote: > Last time I used Django (pre 1.0) it was recommended to always use > trunk since the last released version was too outdated. Has this > changed? Yes. 0.96 -> 1.0 involved a large number of backwards-incompatible changes, so many people simply followed trunk so that they could make changes as they went rather than having a single huge upgrade process. >From 1.0 on, this is not a problem because compatibility is preserved between releases. Thus, your best bet (unless you're a developer actively working on Django itself, and interested in helping to develop new features or fix new bugs) is simply to use the latest release (Django 1.0.2). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: djangobook.com sourcecode
On Fri, Dec 5, 2008 at 3:45 PM, Manu <[EMAIL PROTECTED]> wrote: > Has the source code for djangobook.com ever released ? Is there a plan > to release it if it is not released ? And lastly does anyone know of > any projects which can provide the comments functionality of > djangobook.com ? If you go and read about the comments system on the site, it tells you (see: http://djangobook.com/about/comments/) exactly where it came from: "Many, many thanks to Jack Slocum; the inspiration and much of the code for the comment system comes from Jack's blog, and this site couldn't have been built without his wonderful YAHOO.ext library. Thanks also to Yahoo for YUI itself." There are even links in that paragraph to help you go find the stuff. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: ModelForm removing blank=True
On Tue, Dec 9, 2008 at 7:50 PM, tenni <[EMAIL PROTECTED]> wrote: > "optional_field" becomes a required field in the Admin. I assume > something is overriding the model's blank=True for this field. Yes. *You* are overriding that. The moment you override a field's definition in a ModelForm is the moment Django assumes you know best, and so Django doesn't do *any* automatic introspection of the model for that field. It simply assumes that the field definition you've given is correct in every respect, and that if it's somehow not correct you will fix it. So if the field has "blank=True" in the model, but you give Django your own custom definition for that field in the form, then Django goes with your custom field (which, in this case, has "required=True" since that's the default for all form fields unless you say otherwise). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: user_id in admin pages
On Wed, Dec 10, 2008 at 6:28 PM, Django Newbie <[EMAIL PROTECTED]> wrote: > This is probably an easy one, but I've tried what make sense to me with > not success. What I want to do is in my admin pages, use the User > module and enter the the user_id of whoever is logged in to add an entry > in one of my foreign key tables. Please search the archive of this mailing list; this exact question has been asked and answered many times before. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: No documentation link on admin interface.
On Fri, Dec 12, 2008 at 6:24 PM, Malcolm Tredinnick wrote: > which isn't as far out of bounds as it looks. You get there from the 1.0 > release notes, to the porting document, which then links to that page. > But, for people coming directly to Django 1.0, we've missed something. > I'll fix that when I get a chance. The default root URLConf created by 'django-admin.py startproject' also includes a pattern for this; you still need to have the admindocs app in INSTALLED_APPS for the default templates to be picked up, but it's a start. If you've got other stuff to hack on, I can put together some docs and commit them over the weekend. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How to return a specified column from database
On Sat, Dec 13, 2008 at 5:55 AM, Lee wrote: >If I want to return a specified column in this situation without > using SQL query (select y from table where x =1), how to do it? There is a method which will do this, and it is listed in the database API documentation alongside all the other querying methods. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Problem with field validation in 1.02
On Tue, Dec 16, 2008 at 7:44 AM, rtmie wrote: > OK, got it working: > changed view code to: > if request.method =='POST': >form = AppUserForm(request.POST,request.FILES) This is covered in the forms documentation; you may want to give it a read to learn how the django.forms module works. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Anyone maintaining a Svn repo for django-registration?
On Tue, Dec 16, 2008 at 8:23 AM, shabda wrote: > Django registration has moved from googlecode to Bitbucket, which > means my projects which are svn:externaled to django-registration > might not get the latest code. Is anyone maintaining an svn repository > which is I can svn:external to? You know that you can just grab the package and install it, right? That's the generally-recommended way to do things. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: ModelForms customization conundrum
On Tue, Dec 16, 2008 at 7:19 AM, sagi s wrote: > So I'm looking at the data available in the template to try to get my > hands dirty and restore all this manually but can't find how all this > magic works. I'm in the debugger looking at the form passed to the > template via the context and this looks like a mountain I'd rather not > climb (I'll spare you the details of the data structure here). There is no "magic" involved in the form; a ModelForm simply introspects the model to get the model class' Field objects and, for each field to be included in the form, calls that Field object's 'formfield()' method to get a form field. Of course, the moment you put a custom form field definition in the form class, it ignores whatever comes from the model in favor of your definition. So, either: 1. Stop overriding the field definition, and instead poke at the attributes you want to change inside your form's __init__ method, or 2. Use the same method the ModelForm uses to get the form field, and then change the attributes you want to change before using the resulting form field object to define your form. It's really not that difficult once you take a look at the code involved; probably no more than a half-dozen lines of code if you're just tweaking a couple of fields. Also, when trying to work out what's happening, a debugger is probably the worst possible choice; the underlying code is quite clear and readable, and is far superior for getting an understanding of how the system works. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: SQL injection hardening
On Wed, Dec 17, 2008 at 11:32 AM, Travis Veazey wrote: > if you have a database you risk > being exposed to SQL injection attacks if you do not harden your app against > them. This is actually two statements: 1. If you have a SQL database, you run some theoretical risk of SQL injection attacks (exactly how much of a risk depends on your own code). 2. If you have a SQL database, you must individually ensure that every application is hardened against SQL injection attacks. The first statement is true. The second statement is only trivially true, because we're talking about programming here. In some languages the common practice is to write and rewrite database-access code from scratch with each new application, requiring the developer to also write and rewrite code to protect against SQL injection with each new application. In other languages -- and Python is one of these languages -- the common practice is instead to either make use of an existing library for database access, or to have a standard, agreed-upon API which will be implemented by all database-access libraries, meaning that the necessary code to harden against SQL injection must only be implemented, at most, *once per database-access library*. In Python there is such a standard, agreed-upon API, and that API is specified by PEP 249[1]. The standard API includes all of the necessary mechanics to prevent injection attacks, by allowing and *encouraging* paramaterized queries, such that the querying API takes the query string and the query parameters as two separate arguments, and will combine them in a known-safe manner to execute the query. As a result, any code which uses a library database-access library implementing PEP 249, and which uses the parameterized query style to interact with that library, is quite reasonably safe against SQL injection attempts. It's worth noting that: 1. The common practice in Python programming is to use parameterized queries, 2. Django's access to your database is entirely mediated through libraries which implement PEP 249, and 3. Django uses parameterized queries. As a result, individual Django applications do *not* generally need to worry about SQL injection (I say "generally", however, because of course an application is free to grab a raw database cursor and do whatever it likes, including executing non-paramaterized queries or otherwise constructing queries in an unsafe fashion, but Django's own object-relational mapper does not do this), because the necessary worrying has already been done and the necessary code has already been written and is already being used automatically. [1] http://www.python.org/dev/peps/pep-0249/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: auth: get_profile(): create if it does not exist.
On Wed, Dec 17, 2008 at 5:21 PM, Malcolm Tredinnick wrote: > This would be the "standard" solution. I thought James Bennett's > django-profiles app did this, but apparently I'm mistaken (it would be > slightly duplicated work if it did, in any case). django-profiles kicks you to a profile-creation view if you try to edit your profile and don't have one already. django-registration, on the other hand, supports passing a callback to create an initial profile for a newly-registered user (in other words, a function which just knows how to create an instance of your profile model with all blank/default values). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: MySpace clone using Django? Is it possible?
On Fri, Dec 19, 2008 at 12:41 PM, lekvar...@gmail.com
wrote:
> Hi, I wanna know wich of the well known frameworks is the best choice
> for myspace-clone community website.
Since you're basically going to be throwing money away no matter what
("cloning" an established player and trying to beat them at their own
game is not a plan for a profitable business), why not avoid building
the site altogether and instead take a nice vacation in the Caribbean?
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Can anyone explain why reverse() never seems to work?
On Sat, Dec 20, 2008 at 3:02 PM, Bradley Wright wrote: > Given the following code, can anyone explain why Django can't reverse > this, because I'm of the opinion that reverse is the flakiest function > ever: The permalink decorator is a shortcut which will, on its own, apply reverse() to what the function returns. Since you're already calling reverse() in the function, you're essentially passing the result of reverse() into another reverse() call. Consult the documentation to see how the decorator is normally used. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: python 3.0
On Fri, Dec 26, 2008 at 3:15 PM, waltbrad wrote: > How much of django's code is broken with python 3.0? The installation instructions and the installation FAQ cover this issue: http://docs.djangoproject.com/en/dev/intro/install/#install-python http://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3-0 -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django i18n for google
On Sun, Dec 28, 2008 at 7:19 PM, Alessandro Ronchi wrote: > Django itselfs permits selecting the i18n language via POST. I think > it should be useful to add also a GET var to set the language, and a > localization middleware catches it. This has been debated to death, and the conclusion is that Django's own i18n system will only support changing language via HTTP POST. Please consult the list archives for details. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: enumerate in templates
On Mon, Dec 29, 2008 at 3:02 AM, Vicky wrote: > command like below is not working... can u suggest a way?? It is very, very, very, very important to read the big warning at the top of the template documentation, which states that the Django template language *is not* just Python code embedded in HTML, and which explains that only the specific things described in the documentation will work. A large part of your problem seems to be that you're ignoring this and simply dumping random Python expressions into a template, when it's clearly stated that you can't do that (well, you can, it just won't do anything useful). You might want to take a step back and go through the template documentation thoroughly, then think about how you're structuring the data that's passed into your templates; in the overwhelming majority of cases, attempts to put this much logic into a template (which is meant to provide the bare minimum of logical constructs needed to present data) imply a problem somewhere else in the code. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: a error occurs while use comment framework
On Mon, Dec 29, 2008 at 3:38 AM, Shuge Lee wrote:
> return render_to_response( 'a.html', {'obj': obj, 'category':
> Category} )
>
> a.html
> ...
> {% load comments %}
> {% render_comment_form for category %}
The problem may be that you are passing Category -- the model which
represents all categories in your database -- instead of a specific
individual category. You may want to read up on the distinction
between a class and an instance of a class for further information.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Do you recommend "Practical Django Projects"?
On Jan 5, 2:21Â am, HB wrote: > Hey, > I'm reading "The Definitive Guide To Django" but it is too out dated. > Do you recommend "Practical Django Projects" instead? > It seems to me that "The Definitive Guide To Django" is more organized > and covers a lot of materials. > What do you think? As the author, I recommend waiting a couple months. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Why Django doesn't force testing?
On Jan 5, 6:04Â am, HB wrote: > Sure, I mean encourage not force :) Your email client apparently failed to generate tests for your message, resulting in a misunderstanding. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Where is the source code for Practical Django Projects?
On Thu, Jul 17, 2008 at 2:14 AM, Phillip Parrin <[EMAIL PROTECTED]> wrote: > I'm also looking for the souce code, mainly i'm looking for the > advanced templates you mention when building the weblog. Did you get > the chance to finish the source? I'm tracking down one other reported issue which -- hopefully -- will be fixed for me soon by the merge of newforms-admin, but which is holding me up a bit as I try to wrap up the tarball. In the meantime, all the relevant code is right there in the book ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Django vs. Kohana
On Wed, Jul 16, 2008 at 6:05 PM, Henrik Bechmann <[EMAIL PROTECTED]> wrote: > Can anyone with experience or knowledge of both Django and Kohana (PHP > framework, son of CodeIgniter) list contexts in which each would be > most appropriate? I'm in a selection process right now with both on > the short list. Both are most appropriate in the context of building a web application. In all honesty, this is something that a random bunch of strangers probably can't help you much with; only you know your actual requirements and only you know your preferences for tools and coding styles, so only you can make this decision. Django's feature set is well-documented, and hopefully other frameworks do the same, so reading through the available documentation and doing a tutorial or two is probably your best bet. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Is Django development active?
On Sun, Jul 20, 2008 at 6:57 AM, Hussein B <[EMAIL PROTECTED]> wrote: > I got that illusion due the slow official releases cycle... Be careful with this logic, because it is misleading. For example: Britain has not had a new Prime Minister since June 2007; does this mean the British Government has not done anything in the past year? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: autodiscover() fails too silently...
On Mon, Jul 21, 2008 at 4:12 PM, Amit Ramon <[EMAIL PROTECTED]> wrote: > autodiscover() goes over INSTALLED_APPS and tries to import their admin > modules. When such a module isn't present, ImportError is caught and > consumed. However, if some admin module do exists, but for some reason it > throws an ImportError (e.g., it tries to load a non-existing module), it will > not be loaded and will not be seen in the admin interface, without any > significant notice. To me this seems like an undesired side-effect, perhaps > even a bug. This is a well-known side effect of anything which needs to import something which might not exist: it is nearly impossible to write robust code that can correctly differentiate: 1. An ImportError raised by a non-existent module 2. A module which exists but whose initialization raises an ImportError The solution is to test your code independently and ensure that it functions correctly before attempting to use it (e.g., write a unit test which attempts to import your admin declarations and fails if an exception is raised in the process; if this test passes, you can rest easy). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Making a Form from a model using ModelForms, but dont want to include the ForeignKey variable in the form
On Mon, Jul 21, 2008 at 4:09 PM, Django_newbie <[EMAIL PROTECTED]> wrote: > This save() fails because the form.is_valid() is not true, and the > Blog(foreignkey) field is missing from the post data, how can i make > this save without letting user choose this blog field? Or is it > necessary that the foreignkey field has to be alwayz chosen from a > form? The documentation for ModelForm covers both: 1. Excluding fields from a ModelForm (thus doing away with attempts to validate those fields), and 2. Getting a "partial" object back from a ModelForm which you can modify before actually saving to your database. Details are available here: http://www.djangoproject.com/documentation/modelforms/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: how to display date nicely
2008/8/18 Will Rocisky <[EMAIL PROTECTED]>: > actually I have to do it in views, not template > I need some pure python code All Python datetime objects support the 'strftime' method, which is what you want to use. Consult Python's documentation for the full details. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Reverse URL Questions
On Thu, Aug 21, 2008 at 1:50 AM, Rodney Topor <[EMAIL PROTECTED]> wrote:
> So: Why is the use of explicit URLs discouraged, especially in
> templates? Why is it better to write {% url
> project_name.app_name.views.results %} in a template than to write /
> results/ (assuming the URLconf maps /results/ to the view results)?
So say you write a blog application. It has an Entry model, and its
get_absolute_url() method looks like this:
def get_absolute_url(self):
return "/weblog/%s/%s/" % (self.pub_date.strftime("%Y/%b/%d"), self.slug)
All is well and good.
Then you need to roll out the same app, on the same server, but for a
different site. And that site doesn't want its weblog entries living
at "/weblog/"; it wants, maybe, "/articles/".
Oops.
Oh, and it turns out that's going to conflict with your news
application, which is already trying to use "/articles/" in its
get_absolute_url(). The news stories are going to have to move to
"/stories/". And instead of having photographs at "/pics/", this site
needs to have them at "/photos/".
And the list goes on.
So you can go mess around with ABSOLUTE_URL_OVERRIDES to try to make
this all work, which is a bit of a nasty hack and requires you to be
constantly duplicating information: not only do you have to lay out
the URL patterns in urls.py, you also have to go hard-code the *same*
sets of URLs in ABSOLUTE_URL_OVERRIDES.
This gets very ugly, very quickly. Trust me, because I've been in that
exact situation and I know from experience that it does not end well.
Or you can just write the get_absolute_url() method to use reverse
resolution so that the only thing you have to do is write the URL
patterns you'd be writing anyway, and the reverse resolution will make
sure get_absolute_url() returns the right URL.
> Second: Doesn't the use of get_absolute_url() somehow violate the
> separation of URLs from models?
Nope. In object-oriented programming an object is *supposed* to know
things about itself. You're supposed to be able to take an object and
ask it questions like "who created you?" and "when were you last
updated?" and, yes, even "where can I see you on the public web site?"
Setting up your code so that questions about a model object can be
answered using nothing more than that model object's own API
drastically improves the cleanliness of your code; you've got one
place to go for these questions, instead of fifteen.
> Third: If one is to reverse map views to URLs, which is the best way
> to do it (if there is a best way)?
Clarify what you mean by this?
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: auto urls for methods
On Thu, Aug 21, 2008 at 4:51 AM, Will Rocisky <[EMAIL PROTECTED]> wrote: > Is it possible (like Rails) to not to enter every method and it's url > everytime? And url should go to the method straight unless defined. No. 1. Python's general philosophy is that it's best to explicitly say what you want, rather than have magical implicit things happening behind the scenes (and generally explicit is much easier to debug). 2. Auto-routing URLs takes away your ability to control what you expose of your application. This can create situations ranging from annoying URLs that you'd rather not have people see, all the way up to full-blown oh-hai-i-haxed-ur-site security holes. 3. Auto-routing only works if you're following an extremely narrow interpretation of web development patterns, namely "strict" MVC with a controller_name/view_name/object_id layout, and there are problems both with that narrow interpretation and with the conventions it foists upon you (which this margin is too short to contain). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: QuerySets are scary!
On Sat, Aug 23, 2008 at 3:57 AM, Viktor Nagy <[EMAIL PROTECTED]> wrote: > is this true or both my test and real code are simply wrong? I was > kinda shocked from this The problem here is basically conceptual. You've assumed that, because it supports some of the same operations as a list, a QuerySet must *be* a list -- in other words, that it's a container which holds a collection of objects. So while the things you're trying would work with a list (and would work if you used Python's built-in 'list()' function to turn your QuerySet's results into a list) because a list is simply a static collection of objects, they *won't* work on a QuerySet because a QuerySet is actually a representation of some way you're interacting with your database, and as a result has to walk some fine lines between not hitting your DB too often and not giving you stale results. As a general rule, then, whenever you want this sort of behavior, either: 1. Use list() to force your QuerySet into a list of objects you can then work with as a list, or 2. Pull out the object or objects you want, and store them in a variable, because there are situations (like this one) where the QuerySet won't automatically "remember" them for you. The slightly longer technical answer, if you're interested, is that what you're trying will, sort of by accident, work *if and only if* you've already done something which forced the QuerySet to evaluate, perform its query and populate its internal result list. If that hasn't happened yet, repeatedly slicing or indexing into the QuerySet will result in a new query being run each time you do this, with no "remembering" of previously-returned results. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: unregister in old versions of django
On Sun, Aug 24, 2008 at 5:04 AM, aleray <[EMAIL PROTECTED]> wrote: > Really no idea ? Well, you could always do the following: >>> from django.contrib import admin >>> help(admin.site) Which shows you full API documentation for the AdminSite class, listing all of its methods and what they do, including this one: unregister(self, model_or_iterable) | Unregisters the given model(s). | | If a model isn't already registered, this will raise NotRegistered. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: unregister in old versions of django
On Sun, Aug 24, 2008 at 6:40 AM, aleray <[EMAIL PROTECTED]> wrote: > Thanks for the tip, I often forgot the existence of python doc! > However the thing is in the version of django I'm using there is not > admin.site, so no API to unregister. Like I said, the models are > registered with the old fashioned class admin. Then I thought I could > override that class Admin to define it to None, or something like > that, in order to cancel its registration. In that case the only option you have is to edit the Satchmo code to remove the admin declarations. There's no way to programmatically remove models from the old version of the admin. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: HTML in ValidationError?
On Sun, Aug 24, 2008 at 7:07 AM, coan <[EMAIL PROTECTED]> wrote: > I wonder why custom error messages are considered more dangerous than > the help_text in the same form? Because people do things like this: class HackMySiteForm(forms.Form): some_text = forms.CharField(max_length=255) def clean_some_text(self): if not some_validation_check(): raise forms.ValidationError(u"Your submission -- %s -- was not valid" % self.cleaned_data["some_field"]) return self.cleaned_data['some_field'] Which, of course, is a gaping cross-site-scripting hole. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: unregister in old versions of django
On Sun, Aug 24, 2008 at 6:23 AM, James Bennett <[EMAIL PROTECTED]> wrote: > Which shows you full API documentation for the AdminSite class, > listing all of its methods and what they do, including this one: (and of course if you have DJANGO_SETTINGS_MODULE set properly, there's also the command-line 'pydoc django.contrib.admin.sites.AdminSite') -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Showing staff users from another model
On Sun, Aug 24, 2008 at 7:26 AM, Mark <[EMAIL PROTECTED]> wrote:
> Are there better ways to do this?
Yes.
from django.db import models
from django.contrib.auth.models import User
class Car(models.Model):
brand = models.CharField(max_length=20)
color = models.CharField(max_length=10)
owned_by = models.ForeignKey(User, limit_choices_to={ 'is_staff': True })
The model documentation covers the 'limit_choices_to' argument, as
well as the proper syntax for setting up foreign keys.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: limiting choices in admin.ModelAdmin based on request.user
2008/8/25 krylatij <[EMAIL PROTECTED]>: > You can use ThreadLocals middleware > http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser > to get current user No. There is no longer any reason whatsoever to use this in any way in the admin. It was an ugly, fragile hack before and it's unnecessary now because ModelAdmin has a get_form() method -- which receives the HttpRequest object as an argument -- that you can override to tweak the form on a per-request basis. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Module not callable (Practical Django Projects)
2008/8/26 marsii <[EMAIL PROTECTED]>: > But I have the same error still. :-( I'll bet money that you have this: import markdown When the book tells you to do this: from markdown import markdown There's a very important difference. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
ANN: Django 1.0 beta 2 released
As part of the run up to the final Django 1.0 release (scheduled for next week!), tonight we've pushed out Django 1.0 beta 2, including the final new features for 1.0 (mainly a refactoring of django.contrib.comments). As a beta release, we of course don't recommend it for production use, but if you'd like to test it and help us squash bugs for the final release, feel free to grab a copy and pitch in. Release notes: http://docs.djangoproject.com/en/dev/releases/1.0-beta-2/ Download: http://www.djangoproject.com/download/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Complex, somewhat formula...
On Wed, Aug 27, 2008 at 7:41 AM, <[EMAIL PROTECTED]> wrote: > Could I do this with Django? You could do it with Python, and then use Django to make it visible over the Web, yes. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: "core" is not a field constructor argument anymore
On Fri, Aug 29, 2008 at 5:58 PM, Guillaume Lederrey <[EMAIL PROTECTED]> wrote: > After updating to the latest trunk, I get a couple of errors when I > have field that define "core=True". After digging into the code, I > find changeset 8616 (http://code.djangoproject.com/changeset/8616) > that documents that. However, this doesnt seem to be include in the > backward incompatible changes > (http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges). You want to read the section on the admin changes; basically, anything you used to use to specify/control admin behavior (which is what 'core' did) has changed. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Verbose model name in Admin interface
On Mon, Sep 1, 2008 at 4:56 AM, Nick Day <[EMAIL PROTECTED]> wrote: > I have a model called "en". In the admin interface this appears as > "En" on the site administration page and in the breadcrumb trail. http://docs.djangoproject.com/en/dev/ref/models/options/#verbose-name -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Cannot get user profile working.
On Mon, Sep 1, 2008 at 7:22 PM, Alex <[EMAIL PROTECTED]> wrote: > I have set the following in settings.py (among a thousand other > combinations). The value you want is the app label, which is 'core', followed by a dot, followed by the model name, which is 'userprofile'. So 'core.userprofile'. Not 'web.core.userprofile', not 'web.userprofile', not anything with "web" in it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: dumb question model-dictionary
On Mon, Sep 1, 2008 at 10:24 PM, Vance Dubberly <[EMAIL PROTECTED]> wrote: > Hmm perhaps I should do > > foo = Foo.objects.filter(pk=1) > foo_form = FooForm(instance=foo) > data = foo_form.cleaned_data Or you could do what the form itself is doing, namely, using the function django.forms.models.model_to_dict(), which -- as the name implies -- takes a model object and spits back a dictionary whose keys are field names and whose values are the current values on that object. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: dumb question model-dictionary
On Tue, Sep 2, 2008 at 2:30 AM, bruno desthuilliers <[EMAIL PROTECTED]> wrote: > More seriously, it took me 2 minutes playing with a model object in > the interactive shell to come up with what seems a working solution: Yeah, which is why I pointed out the easy wrapper function for it in my email above. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
ANNOUNCE: Security updates for Django trunk, 0.96, 0.95 and 0.91
In accordance with our security policy[1], today the Django project is issuing a set of releases to fix a security vulnerability reported to us. This message contains a description of the vulnerability, a description of the changes made to fix it, and pointers to the patches for each supported version of Django. Description of vulnerability The Django administration application, as a convenience for users whose sessions expire, will attempt to preserve HTTP POST data from an incoming submission while re-authenticating the user, and will -- on successful authentication -- allow the submission to continue without requiring data to be re-entered. Django developer Simon Willison has presented the Django development team with a proof-of-concept cross-site request forgery (CSRF) which exploits this behavior to perform unrequested deletion/modification of data. This exploit has been tested and verified by the Django team, and succeeds regardless of whether Django's bundled CSRF-protection module is active. Affected versions = * Django development trunk * Django 0.96 * Django 0.95 * Django 0.91 Resolution == As it represents a persistent vector for CSRF attacks, this behavior is being removed from Django; henceforth, attempted posts from users whose sessions have expired will be discarded and the data will need to be re-entered. This is, then, backwards-incompatible with existing behavior and may be considered a feature removal; however, the Django team feel that the security risks of this feature outweigh its minor utility. The fix for this issue was applied to the Django repository in changeset 8877, which contains the relevant changes for each affected version:: http://code.djangoproject.com/changeset/8877 Based on these changes, the Django team is issuing three new releases: * Django 0.96.3: http://www.djangoproject.com/download/0.91.3/tarball/ * Django 0.95.4: http://www.djangoproject.com/download/0.95.4/tarball/ * Django 0.91.3: http://www.djangoproject.com/download/0.96.3/tarball/ The relevant patch has been applied to Django trunk as well, and so will be included in the forthcoming Django 1.0 release candidate (to be issued later today) and the final Django 1.0 release. All users of affected Django versions are encouraged to upgrade immediately. A file containing the MD5 and SHA1 checksums of the new release packages has been placed on the ``djangoproject.com`` server:: http://media.djangoproject.com/pgp/django-security-releases-20080901.checksums.txt This file is PGP-signed with the Django release manager's public key. This key has the fingerprint ``0x8C8B2AE1`` and can be obtained from, e.g., the MIT PGP keyserver:: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8C8B2AE1 Release manager's note == If you are currently maintaining and distributing a packaged version of Django (e.g., for a Linux or other Unix distribution), or if you are a hosting company which officially supports Django as an option for customers, and you did **not** receive an advance notification of this issue, please contact Django's release manager (James Bennett, james at b-list dot org) as soon as possible so that you can be added to the list of known distributors who receive such notifications. [1] http://www.djangoproject.com/documentation/contributing/#reporting-security-issues -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
ANNOUNCE: Django 1.0 release candidate now available
We've just put up the package for the first Django 1.0 release candidate; this package contains all of the progress made on Django through the alpha and beta releases, and is fairly close to the final Django 1.0 release. It's still not recommended for production use, but we do encourage everyone to check it out and help us identify any remaining bugs; the next step in this process is the final Django 1.0 release, and we need your help to make it as smooth as possible. Download: http://www.djangoproject.com/download/ Release notes: http://docs.djangoproject.com/en/dev/releases/1.0/ Package checksums: http://media.djangoproject.com/pgp/Django-1.0-rc_1.checksum.txt -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Where is the source code for Practical Django Projects?
On Tue, Sep 2, 2008 at 8:13 PM, Joeyx2 <[EMAIL PROTECTED]> wrote: > Still waiting on that source code? Guys, I promise you all that there will be a loud and triumphant announcement on my blog when the package goes up. With Django 1.0 landing and the final changes from that still being worked on, it's still going to take a bit of time. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
ANNOUNCE: Django 1.0 released
The Django team is pleased to announce the release of Django 1.0 this evening: Download: http://www.djangoproject.com/download/ Release notes: http://docs.djangoproject.com/en/dev/releases/1.0/ Have fun with it, and we'll see you in a few days for DjangoCon. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Setting up Django in apache
On Wed, Sep 3, 2008 at 10:28 PM, Pepsi330ml <[EMAIL PROTECTED]> wrote:
> Thus i cannot use the PythonOption django.root
> Is there other alternative?
Well, what you can generally do to work around this if you have an
older Django is to create a new file, say, root_urls.py in your
project, and set it up like a normal URLConf, but in it put only a
single pattern:
(r'^your_site_root/', include('your_real_urls.py'),
Then make this your root URLConf.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: using 1.0 instead trunk
On Thu, Sep 4, 2008 at 4:28 AM, Aljosa Mohorovic <[EMAIL PROTECTED]> wrote: > since i'm using subversion for my sites in svn:externals i have django > trunk and now i'm switching to 1.0 tag. > so what i'm actually asking is if i'm using 1.0 tag in svn:externals > does it mean that i'm guaranteed that only security fixes will be > updated in 1.0 tag or should i expect some other changes? The 1.0 tag is frozen for all time; no changes will ever be made to it, and it serves as a historical reference point. In the past we've branched off from the release tags to create support trees (e.g., "0.96-bugfixes", "0.95-bugfixes", etc.) for security issues. Since there are some quirks to be ironed out with post-1.0 development, we haven't yet done that for 1.0, but there will be a solution in place soon. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: last security fix
On Thu, Sep 4, 2008 at 2:29 PM, pavel srb <[EMAIL PROTECTED]> wrote: > please, due to http://www.djangoproject.com/weblog/2008/sep/02/security/ > i would like to know, when there will be security patch for debian > etch version I follow the Debian bug tracker and lists for Django-related items, and it appears they've already got new packages in the queue, though it takes a bit of time for everything to work its way through their process. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: cannot import name entrys
It seems you're trying to take a Django application which was written three releases cycles (or more) ago (since the syntax in some of your code samples screams out that it's from an app written against 0.90 or 0.91) and attempting to simply fix it piecemeal to run on 1.0. Speaking from experience, that's not going to work and you're going to spend several months posting to the list saying, "OK, I got a new error, now what?" You've already been given a link to the backwards-incompatible changes list, which in turn links back to archived lists of changes going all the way to the oldest versions of Django. Your best bet is to: 1. Work out exactly which version of Django (most likely 0.91) your application was originally written for. 2. Spend some quality time with the documentation for the Django 1.0 release to thoroughly learn how things work now. 3. Work through the list of changes, one step at a time, until you're on 1.0. This will be tedious, but fortunately we've been extremely obsessive about documenting each and every change you'll need to deal with and how to work through it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: possible bug in django-admin
On Tue, Sep 9, 2008 at 4:15 AM, Benedict Verheyen <[EMAIL PROTECTED]> wrote: > i tried to do a django-admin startproject and it > said that startproject wasn't a valid command. > Weird. django-admin help indeed didn't show the startproject command. This is currently intended behavior and I believe it's now documented as well; the "startproject" command is disabled when django-admin.py detects that you already have and are working with an existing project, because "startproject" doesn't really make sense in those cases. Generally speaking, if you've set DJANGO_SETTINGS_MODULE or pass the "--settings" argument, the command will be disabled. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: updating entry from form in django 1.0!?
On Wed, Sep 10, 2008 at 2:00 PM, David <[EMAIL PROTECTED]> wrote: > and I wanted to have something along these lines but don't know how to > convert to the new convention Perhaps you should check out the documentation for generating forms from models, which contains descriptions of how to do this: http://docs.djangoproject.com/en/dev/topics/forms/modelforms/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: How to syncdb programatically (django standalone script) ?
On Mon, Sep 15, 2008 at 8:50 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> This is k=nd of a wild-assed guess. Please tell me if it works.
>
> from django.core.management import call_command
> call_command('syncdb')
That is the way to do it; the whole manage.py/django-admin.py system
was refactored a while back to expose that interface so people can
reach in and call commands programmatically.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Cannot resolve keyword 'user' into field. Choices are: xxx, yyy, zzz
On Mon, Sep 29, 2008 at 2:02 AM, jim <[EMAIL PROTECTED]> wrote: > This gives me an error: > Cannot resolve keyword 'user' into field. Choices are: xxx, yyy, zzz > > Any ideas as to what may be causing this? Your profile model must have a ForeignKey or a OneToOneField pointing to User, and the name of that field must be 'user'. This is because, under the hood, "request.user.get_profile()" is actually "YourProfileModel.objects.get(user=request.user)"; if your profile model has no field named "user", you'll get the error message above. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: status of per-object-level permission
On Tue, Sep 30, 2008 at 5:07 PM, kajigga <[EMAIL PROTECTED]> wrote: > I've just come across this Django branch called "RowLevelPermission". > http://code.djangoproject.com/wiki/RowLevelPermissions. I have yet to > try it out. Don't bother; it's dead as a doornail and has been for quite a long time. As a general rule, if a branch hasn't had a commit in 15 months, it's probably not what you're looking for. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: alphabetize options in a ForeignKey dropdown?
2008/10/2 Jarek Zgoda <[EMAIL PROTECTED]>:
> Anyway, I seem to be unable to change ordering of FKs relating to User
> object. Any hint?
So, suppose you have the following model, a simple user profile:
from django.contrib.auth.models import User
from django.db import models
class UserProfile(models.Model):
likes_spam = models.BooleanField
twitter_username = models.CharField(max_length=255)
website = models.URLField()
user = models.ForeignKey(User)
And suppose you want the list of users, in the admin, to be
alphabetized by username. In your admin.py file, you'd do:
from django.contrib import admin
from django.contrib.auth.models import User
from django import forms
from yourapp.models import UserProfile
class UserProfileForm(forms.ModelForm):
user = forms.ModelChoiceField(queryset=User.objects.order_by('username'))
class Meta:
model = UserProfile
class UserProfileAdmin(admin.ModelAdmin):
form = UserProfileForm
admin.site.register(UserProfile, UserProfileAdmin)
There are other ways to come at this if you just want to override a
single field, but I'm a fan of just doing the form.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: SQL: Migration How To?
On Fri, Oct 3, 2008 at 11:36 PM, Benjamin Buch <[EMAIL PROTECTED]> wrote: > Is there somewhere a place in the documentation where SQL migration > strategies are explained a little? No. For the moment, the only "official", if it can be called that, way to do this is via SQL's ALTER TABLE statement. There are several third-party projects attempting to make this easier, but none of them are part of Django. > I don't know SQL As an aside, this is probably an indicator that you should stop and learn SQL. Trying to write applications which are backed by a SQL-based DB, when you don't understand the language of that DB, will only end in tears. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: forms.BooleanField
On Sun, Oct 5, 2008 at 11:07 AM, globophobe <[EMAIL PROTECTED]> wrote:
> I encountered this when I upgraded from my recent copy of 0.97 django
> to 1.0-final. Why does MyForm not validate when instantiated as m =
> MyForm({'bfield':'False'})?
Because the field doesn't have "required=False"; all form fields are
required by default unless you say otherwise. A BooleanField
translates into a checkbox, and the only way to "require" a value for
a checkbox is to require it to be checked (i.e., to have a value which
evaluates true); any false value, or the absence of a value, will
fail.
This has been the documented behavior for a long time, though
occasional bugs would cause it not to actually work that way.
(also, there have been several long discussions about this behavior
leading up to it being finalized as it currently works, so if you'd
like to take up an argument against it you probably want to start by
finding them in the archive)
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Multiple ManyToMany relations with the same class
On Mon, Oct 6, 2008 at 3:52 PM, xkill <[EMAIL PROTECTED]> wrote: > But it doesn't work, how can I do it? The error message you will receive will tell you what to do. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: model definition must come before reference in models.ForeignKey?
On Fri, Oct 10, 2008 at 6:39 PM, Fenwick, Jacob L. <[EMAIL PROTECTED]> wrote: > I suppose this makes sense, but what if I have a very complicated hierarchy? > Such as if I have three tables, and their foreign keys relationships form a > triangle? The documentation for ForeignKey covers this case; you probably want to read a bit further on in the docs to see the examples of this. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: contrib admin and admindocs problem
On Sun, Oct 12, 2008 at 5:51 AM, Nash <[EMAIL PROTECTED]> wrote: > I get this error, you can see a paste here: http://dpaste.com/83932/ > The admin site doesn't work on production at all, on the testserver it > works after a refresh. You appear to have an error in your own code, as evidenced by the final line of the traceback (when in doubt, always *read* the error message): "Tried view_form in module px.heroes.views. Error was: 'module' object has no attribute 'view_form'" This says that your code tries to access something named "view_form" in the module "px.heroes.views", but that there is no such thing available. This raises an exception, which breaks everything. (and the reason why you see this in the admin is because the admin uses reverse URL resolution, which means it has to be able to import all of your views -- any error, anywhere, in any of your views, will break everything) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: How to unit test form clean methods
On Sun, Oct 12, 2008 at 8:30 PM, meppum <[EMAIL PROTECTED]> wrote: > I would like to be able to unit test my forms. Specifically, I'd like > to be able to test individual clean methods, but I get errors when I > try to call cleaned methods directly. Below is an example of testing a > registration form. I couldn't find any documentation on this. First, create an instance of the form using a dictionary of data which should fail, then check that is_valid() is False and inspect the error dictionary to make sure it got the right message. Then, create an instance using a dictionary that should pass, and check that is_valid() is True. django-registration does this in its unit-test suite (form tests start at line 145): http://www.bitbucket.org/ubernostrum/django-registration/src/tip/registration/tests.py -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Virtual Methods?
On Mon, Oct 13, 2008 at 6:16 AM, DrMeers <[EMAIL PROTECTED]> wrote: > I am writing a Blog-style django site which needs to render a > collection of Item objects. Item is the root Super class for a whole > bunch of sub-classes -- Photo, Video, Quote, News, etc. I want to be > able to iterate through Item.objects.all() and ask each Item to > render() itself based on which sub-class it is. I'm from a C++ > background, and my virtual-method approach isn't working -- it just > calls the Item.render() method instead of the appropriate sub-class > one. This is a quirk of the way inheritance works in the ORM; when you ask for a QuerySet of Item instances, you get Item instances. Not Item-but-really-some-other-subclass instances, but actual genuine Item instances, whose methods are the methods defined on the Item class. This happens because inheritance, under the hood, is simply a one-to-one relation between a pair of objects; one is the "parent" and one is the "child". And they really are *two* objects, not one, so to get the methods of the "child" you have to be working with the "child" object (which is accessible as described in the documentation). They're also pulling from two different tables. The longer answer is that inheritance in a model hierarchy -- because it's dealing with the impedance mismatch of needing to map onto a relational database -- doesn't behave the way inheritance behaves in other situations, and generally it should be a last, rather than a first, resort when you're modelling your data (unless you're just doing things like using an abstract model class to avoid repetitive field declarations -- note that an abstract model class cannot be directly instantiated, so switching your setup to use one still wouldn't get the behavior you're aiming for). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: current user
On Tue, Oct 14, 2008 at 3:10 PM, gearheart <[EMAIL PROTECTED]> wrote: > http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser Sigh. I guess this is the part where I go edit that wiki page to point people to the better solution? Yeah, I think this is the part where I go edit that wiki page. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
