=== nhandler_ is now known as nhandler === nhandler_ is now known as nhandler === nhandler_ is now known as nhandler === yofel_ is now known as yofel === kermiac is now known as kermiac_ === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: Learning Django - Current Session: Learning Django - Day 2 - Instructor: mhall119|work || Questions in #ubuntu-classroom-chat [18:00] I guess that means it's time to start [18:01] can I see a show of hands for who's here? [18:02] alright, great [18:03] before I get started, does anyone need a recap of yesterday's session? [18:03] okay, yesterday we created our django project and application [18:03] as I explained, a Django project is a collection of related applications [18:04] we also created a very simple view, which in Django is just a function that takes an HttpRequest object, and returns an HttpResponse object [18:04] we then wired that view to a URL pattern [18:06] if you were not here yesterday, you can grab the code we stopped with by running "bzr branch -r tag:day1.7 lp:classroom-scheduler" [18:06] sorry, my connection is suddenly lagging [18:07] so today we're going to create our Models [18:07] Models are an integral part of a Django application [18:08] they provide an interface between your code and the backend database [18:08] they can also be used to generate forms and pages with a minimal amount of work on your part [18:09] so, first things first, cd into your classroom-scheduler directory, which should be at day1.7 [18:09] and run "bzr pull -r tag:day2.1" [18:10] now if you open classroom_scheduler/class/models.py you will see an empty model called "Session" [18:10] those of you who were here yesterday will remember that we are building an app to track teaching sessions here in #ubuntu-classroom [18:11] "Session" will be our model for defining the data we are going to work with for those sessions [18:13] now, it's time to give this model some definition [18:13] Django models store metadata in an inner class aptly named "Meta" [18:14] so if you "bzr pull -r tag:day2.2" you will see the new Meta class in Session [18:15] now Meta has several optional attributes you can give it, I've only specified verbose_name and verbose_name_plural [18:15] these are what Django will use when displaying the Model's name [18:15] these too are optional, if we had not defined them Django would assume them from the class's name [18:16] now, our model still doesn't have any data of it's own, so we have to add Fields [18:16] Django supplied a rich assortment of Field types you can use [18:16] you can also define your own,should you ever find that you can't accomplish what you need with those built into Django [18:17] run "bzr pull -r tag:day2.3" to get the fields for our model [18:18] this will give you a look at just a few of the available fields [18:18] you can see we define a teacher, title, start and end dates and a url field [18:19] When you access these fields from an instance of your model, they are automatically converted to python datatypes [18:19] so if you had mysession=Session(title="Learning Django") [18:19] mysession.title would be a Django str (string) type [18:20] DateTimeFields are treated like datetime variables [18:20] so you can do mysession.start_time = datetime.datetime.now() [18:20] and Django handles all of the internals for you [18:21] speaking of internals, now that we have our Model, we need to create the tables in our database for them [18:21] to do this, run "python manage.py syncdb" from the project directory [18:21] those of you who were here yesterday may remember that step [18:22] whenever you add new Models, you have to run syncdb again to have Django create the necessary tables [18:24] any questions so far? [18:24] hemanth asked: whenever we add/modify the Models we must syncdb right? [18:25] you add Models with syncdb, but it's not smart enough to know how to handle modifications [18:25] there is a separate project, django-south, that lets you automate modifications to tables [18:25] but that's a subject for another lesson [18:27] okay, so another very powerful tool Django provides is the concept of ForeignKeys and Many2Many relationships [18:27] not only does it provide for these in your python code, but it handles them in the database as well [18:28] suppose we wanted to add a Course model, that would be a collection of Sessions on a common topic [18:28] much like this series of lessons [18:28] we would want to link a Session to a Course through a ForeignKey field [18:28] if you run "bzr pull -r tag:day2.4" you will get exactly that [18:29] now if you look at class/models.py you will see that we added a Course model that is just a title, start and end dates [18:30] and at the bottom of the Session model, you will see a new field named 'course' that is a ForeignKey to this new model [18:30] again, Django will map this field to a python object, in this case it will be our Model class 'Course' [18:31] so you can do mycourse = Course(title="Learning Django Week") [18:31] mysession.course = mycourse [18:31] and again Django handles the mappings between python and the database for you [18:32] any questions before we move on? [18:33] guess not, okay [18:34] so, another common object-oriented paradigm is the notion of inheretance [18:34] and it turns out that Django can handle this too [18:34] if you sub-class a Django Model, it will create a new table with only your new fields, using the original model's table for the interited fields [18:35] you can also define a model as "abstract", by setting abstract=True in it's Meta class. Doing that will keep Django from making a table for that parent class, and all fields will live in the table it creates for child classes [18:36] now, Jono Bacon has this really cool program called Lernid that some of you may have used (or may be using right now) [18:36] it basically combines #ubuntu-classroom, #ubuntu-classroom-chat with a web browser, terminal and schedule listing all in one app [18:37] it also has the ability to display slides from a downloaded PDF [18:37] so, if we wanted to capture the slide URL for a session using Lernid, we can create a subclass of our Session model for this field [18:38] and if run "bzr pull -r tag:day2.5" you will see that I did exactly that [18:38] we now have a model called LernidSession that inherits from Session, and adds a URLField for slides [18:39] and if you run "python manage.py syncdb" again, you will see it making the new table for this model [18:40] < hemanth> QUESTION : can something like mysession.course = Course(title="Learning Django Week"); be achieved [18:40] ? {inheritance} [18:40] that's not inheritance, that's just creating a new Course instance and assigning it to mysession.course [18:40] did you mean something else? [18:41] hemanth? [18:42] oh, no, the Session won't inherit the methods of Course [18:42] mysession.course will be an instance of Course [18:42] so you can do mysession.course.title [18:42] this of mysession.course as just a variable attached to mysession that holds an instance of Course [18:43] but if you did mylernid = LernidSession(title="Lernid Session"), then mylernid would have the fields from both Session and LernidSession [18:44] so you could also do: mylernid.course = mysession.course [18:44] does that make sense? [18:45] okay [18:45] now we have our wonderful models, lets go somewhere where we can see them [18:46] Django provides a very powerful Admin application that lets you manage instances of your models [18:46] it is located in django.contrib.admin [18:46] so enable it, we need to add it to INSTALLED_APPS, create a URL mapping to it, and finally register which models we want Admin to be aware of [18:47] running "bzr pull -r tag:day2.6" will get all of that for you [18:47] you should have a new file under class/admin.py [18:48] if you look in there, you can see that we are registering each of our models with the admin application [18:48] we also wired the application to the url '^admin/' [18:49] once again, we need to run "python manage.py syncdb", because we introduced a new application to INSTALLED_APPS, and it has it's own set of models that need a database table created [18:50] then, run "python manage.py runserver" and it should start up Django on localhost [18:51] it'll say Django is running on http://127.0.0.1:8000/ or something similar [18:51] then if you go to http://127.0.0.1:8000/admin/ it will take you to the login screen for the admin app [18:51] the login is the same one that was created on the first syncdb we did yesterday (or today, if you didn't do it yesterday) [18:52] did everybody get to logged in to the admin? [18:53] < hemanth> QUESTION : The current URL, , didn't match any of these.Should i change anything in settings.py ? [18:53] you need /admin/ after the host:port [18:54] alright, so once you're in, you will see the "Class" section has our models listed [18:54] each application in your project that registeres models will have it's own section === yofel_ is now known as yofel [18:55] from here you can add/edit/delete models [18:55] you will see that "Class Session" (the verbose_name for Session), as well as "Lernid Session" have a field for Course, because it is a foreign key [18:56] go ahead and create a new Course instance, and then a Class Session instance for that course [18:57] you'll notice while you're doing this that the labels come from the verbose_name attribute of the field [18:57] and the help_text for the field is displayed below the widget === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi [19:00] < hemanth> QUESTION : no such column: class_session.course_id; i had ran syncdb [19:00] can you guys still see me? [19:01] okay, we're running over, but I don't think anyone is on right away, so we'll continue [19:01] remember how I said that syncdb wasn't smart enough to edit a model's table? [19:01] well, we added Session.course as a ForeignKey after we ran the syncdb to create teh Session table [19:02] so we need to clear out our existing table structure, and put the correct one in place [19:02] with django-south, we could just add the one field, but for now we'll just start over [19:02] to do that run "python manage.py reset class" [19:02] this will drop all the tables for the "class" application, and rebuild them according to the current model [19:03] once you've done that, you can go back into the admin and add your courses and sessions [19:04] no, reset should recreate all the tables that syncdb would create [19:04] sorry [19:05] so, when you create your instances, you will probably notice that they're being displayed as "Session object" or "Course object" [19:05] well that's not very useful [19:05] we want them to identify themselves as something meaningful to us [19:05] to do that, we overwrite the __unicode__ method in the Model [19:06] if you run "pull -r tag:day2.7" you will see that I do this for Course and Session [19:06] I don't need to do it for LernidSession, because it will inherit the __unicode__ implementation from Session [19:07] now when you go back into the Admin, you will see Cources listed by their title, and Sessions listed by their title and teacher [19:07] and that concludes (a little late) day 2 of this course [19:08] tomorrow we will begin looking at Django Forms, another powerful set of classes that lets us connect users to our Models [19:08] again, you can email me at mhall119@ubuntu.com should you have any questions [19:09] thank you all for attending, and I will see you tomorrow === dclarke_ is now known as SmartSsa