Hi,
I have tried to follow the tutorial for 1.2.1 but i'm having problems
the explanation for adding __unicode__() or __str__() to the class to
make it to list the polls correctly without any success.
addition of this code did not really fix anything in the polls
listings;
lass Poll(models.Model):
# ...
def __unicode__(self):
return self.question
class Choice(models.Model):
# ...
def __unicode__(self):
return self.choice
This is all that it has returned;
[<Poll: Poll object>]
What is wrong?
David
On Aug 2, 1:31 pm, tiemonster <m...@tiemonster.info> wrote:
> Thank you so much for the valuable feedback regare ding my post. I value
> peer review, and take it very seriously. I've updated the article to
> attempt to address your concerns. Please review it at your convenience
> to ensure that your concerns are addressed appropriately.
>
> http://www.tiemonster.info/a/24005/
>
> Regards,
> Mark Cahill
>
> On Jul 31, 11:49 am, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:> On Fri, Jul 30, 2010 at 8:14 PM, tiemonster <m...@tiemonster.info>
> wrote:
> > > I cover some of the new changes in Django 1.2 in this article:
> > >http://www.tiemonster.info/a/24005/
>
> > > Most of this information comes straight from the changelist. Others
> > > were things that the core developers must have assumed were common
> > > sense, but that I didn't think about when upgrading. If you run across
> > > anything that's not on the list, let me know and I'll update the
> > > article.
>
> > Hi Mark,
>
> > Since this conversation is happening in the context of a backwards
> > compatibility discussion, I want to provide some clarification to a
> > couple of elements of your blog post:
>
> > * Although we have introduced a new format for defining databases,
> > you aren't required to make any modifications in order to upgrade.
> > Old-style DATABASE_* settings will continue to work, as the release
> > notes describe [1].
>
> > [1]http://docs.djangoproject.com/en/dev/releases/1.2/#specifying-databases
>
> > * The problem with database caching isn't a backwards incompatible
> > problem; it's a bug with the database cache backend when used with
> > multiple database support. Since Django 1.1 didn't have support for
> > multiple databases, it's impossible for a Django 1.1 project to
> > experience a backwards incompatibility problem here. It is, however, a
> > bug in the a Django 1.2 feature. Ticket #13946 is tracking the
> > problem; it is on my radar, and I've just updated the triage state to
> > ensure that it doesn't get forgotten.
>
> > * If you have an existing project, the introduction of CSRF
> > protection in Django 1.2 shouldn't pose any obstacle to upgrading.
> > CSRF protection is turned on by default in new projects, but you need
> > to manually turn it on for existing projects (i.e., you need to add
> > the new middleware). If you don't add the new middleware, you don't
> > need to do anything in order to run your project under Django 1.2. The
> > only potential backwards incompatibility is if you have written custom
> > templates to override the default templates provided by Django's admin
> > -- but this is clearly highlighted in the release notes [2].
>
> > [2]http://docs.djangoproject.com/en/dev/releases/1.2/#csrf-protection
>
> > * Your comments about messages correctly points out that the changes
> > are completely transparent, and require no immediate action for
> > compatibility.
>
> > * I don't know where you've got your information on the changes to
> > the unit test system, but your comments are (to use a complex Latin
> > term) wrong :-) The example you point to [3] is exactly the same
> > example that existed in the docs for Django 1.1 [4] and Django 1.0
> > [5]. Django's Test Client has never had a dependency on either the
> > base unittest library or Django's own unittest extensions. Django 1.2
> > didn't introduce any significant changes to the test client. There
> > were some changes to the test runner -- the utility that sets up and
> > executes the test environment -- but again, those changes should be
> > completely transparent, and require no immediate change when
> > upgrading.
>
> > [3]http://docs.djangoproject.com/en/1.2/topics/testing/#example
> > [4]http://docs.djangoproject.com/en/1.1/topics/testing/#example
> > [5]http://docs.djangoproject.com/en/1.0/topics/testing/#example
>
> > * Your point about admin media is generally good advice, but isn't a
> > backwards compatibility problem. Yes, Django 1.2 has new admin media
> > files, and you will need to have a complete and correct checkout of
> > those files served by your media provider (CDN or otherwise).
>
> > As I said previously, we take backwards compatibility very seriously
> > as a project. Unless you have been tinkering with internals or relying
> > on behavior that is buggy, you should be able to upgrade from Django
> > 1.1 to Django 1.2 without being required to make *any* changes to your
> > code. This has been my experience on all projects that I have updated.
> > If anyone can provide a documented example to the contrary, then that
> > is a bug that should be fixed, and may well be sufficient to trigger a
> > point release.
>
> > Note that I said *required* to make changes. There are many updates
> > that are worthwhile making that aren't required (and won't be until
> > Django 1.4 is released). Enabling CSRF protection is a good idea for
> > security sake. Updating database settings will enable new
> > architectural options. Switching to the new messaging framework allows
> > for anonymous users to receive messages, and also allows for cookie
> > based messaging. However, none of these modifications are required in
> > order to update to Django 1.2.
>
> > Yours,
> > Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
