Changes between Version 3 and Version 4 of DevModelCreation

Timestamp:

Oct 26, 2007, 8:55:38 AM (17 years ago)

Author:

Thomas Güttler <hv@…>

Comment:

str to unicode

DevModelCreation

@@ -16 +16 @@
     static = "I am a normal static string attribute"
 
-    def __str__(self):
+    def __unicode__(self):
         return name
 }}}
@@ -37 +37 @@
 Each attribute is then added to the new class object. This is done by calling {{{Model.add_to_class}}} with the attribute name and object. This object could be something like a normal unbound method, or a string, or a property, or -- of most relevance here -- a {{{Field}}} subclass that we want to do something with. The {{{add_to_class()}}} method checks to see if the object has a {{{contribute_to_class}}} method that can be called. If it doesn't, this is just a normal attribute and it is added to the new class object with the given name. If we do have a {{{contribute_to_class}}} method on the new attribute object, this method is called and given a reference to the new class along with the name of the new attribute.
 
-Putting this in the context of our example, the ''static'' and ''!__str!__'' attributes would be added normally to the class as a string object and unbound method, respectively. When the ''name'' attribute is considered, {{{add_to_class}}} would be called with the string ''name'' and an instance of the {{{models.CharField}}} class (which is defined in {{{fields/__init__.py}}}). Note that we are passed an ''instance'' of {{{CharField}}}, not the class itself. The object we are passed in {{{add_to_class}}} has already been created. So that object knows it has a ''maxlength'' of 50 in our case. And that the default verbose name is not being overridden and so on. {{{CharField}}} instances have a {{{contribute_to_class}}} method, so that will be called and passed the new {{{Example}}} class object and the string ''name'' (the attribute name that we are creating).
+Putting this in the context of our example, the ''static'' and ''!__unicode!__'' attributes would be added normally to the class as a string object and unbound method, respectively. When the ''name'' attribute is considered, {{{add_to_class}}} would be called with the string ''name'' and an instance of the {{{models.CharField}}} class (which is defined in {{{fields/__init__.py}}}). Note that we are passed an ''instance'' of {{{CharField}}}, not the class itself. The object we are passed in {{{add_to_class}}} has already been created. So that object knows it has a ''maxlength'' of 50 in our case. And that the default verbose name is not being overridden and so on. {{{CharField}}} instances have a {{{contribute_to_class}}} method, so that will be called and passed the new {{{Example}}} class object and the string ''name'' (the attribute name that we are creating).
 
 When {{{Field.contribute_to_class}}} (or one of the similar methods in a subclass of {{{Field}}}, it does not add the new attribute to the class we are creating (''Example''). Instead it adds itself to the {{{Example._meta}}} class, ending up in the {{{Example._meta.fields}}} list. If you are interested in the details you can read the code in {{{fields/__init__.py}}} and I am glossing over the case of relation fields like {{{ForeignKey}}} and {{{ManyToManyField}}} here. But the principle is the same for all fields. The important thing to realise is that they are not added as attributes on the main class, but, rather, they are stored in the {{{_meta}}} attribute and will be called upon at save or load or delete time.