=== 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
mhall119|workI guess that means it's time to start18:00
mhall119|workcan I see a show of hands for who's here?18:01
mhall119|workalright, great18:02
mhall119|workbefore I get started, does anyone need a recap of yesterday's session?18:03
mhall119|workokay, yesterday we created our django project and application18:03
mhall119|workas I explained, a Django project is a collection of related applications18:03
mhall119|workwe also created a very simple view, which in Django is just a function that takes an HttpRequest object, and returns an HttpResponse object18:04
mhall119|workwe then wired that view to a URL pattern18:04
mhall119|workif 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
mhall119|worksorry, my connection is suddenly lagging18:06
mhall119|workso today we're going to create our Models18:07
mhall119|workModels are an integral part of a Django application18:07
mhall119|workthey provide an interface between your code and the backend database18:08
mhall119|workthey can also be used to generate forms and pages with a minimal amount of work on your part18:08
mhall119|workso, first things first, cd into your classroom-scheduler directory, which should be at day1.718:09
mhall119|workand run "bzr pull -r tag:day2.1"18:09
mhall119|worknow if you open classroom_scheduler/class/models.py you will see an empty model called "Session"18:10
mhall119|workthose of you who were here yesterday will remember that we are building an app to track teaching sessions here in #ubuntu-classroom18:10
mhall119|work"Session" will be our model for defining the data we are going to work with for those sessions18:11
mhall119|worknow, it's time to give this model some definition18:13
mhall119|workDjango models store metadata in an inner class aptly named "Meta"18:13
mhall119|workso if you "bzr pull -r tag:day2.2" you will see the new Meta class in Session18:14
mhall119|worknow Meta has several optional attributes you can give it, I've only specified verbose_name and verbose_name_plural18:15
mhall119|workthese are what Django will use when displaying the Model's name18:15
mhall119|workthese too are optional, if we had not defined them Django would assume them from the class's name18:15
mhall119|worknow, our model still doesn't have any data of it's own, so we have to add Fields18:16
mhall119|workDjango supplied a rich assortment of Field types you can use18:16
mhall119|workyou can also define your own,should you ever find that you can't accomplish what you need with those built into Django18:16
mhall119|workrun "bzr pull -r tag:day2.3" to get the fields for our model18:17
mhall119|workthis will give you a look at just a few of the available fields18:18
mhall119|workyou can see we define a teacher, title, start and end dates and a url field18:18
mhall119|workWhen you access these fields from an instance of your model, they are automatically converted to python datatypes18:19
mhall119|workso if you had mysession=Session(title="Learning Django")18:19
mhall119|workmysession.title would be a Django str (string) type18:19
mhall119|workDateTimeFields are treated like datetime variables18:20
mhall119|workso you can do mysession.start_time = datetime.datetime.now()18:20
mhall119|workand Django handles all of the internals for you18:20
mhall119|workspeaking of internals, now that we have our Model, we need to create the tables in our database for them18:21
mhall119|workto do this, run "python manage.py syncdb" from the project directory18:21
mhall119|workthose of you who were here yesterday may remember that step18:21
mhall119|workwhenever you add new Models, you have to run syncdb again to have Django create the necessary tables18:22
mhall119|workany questions so far?18:24
ClassBothemanth asked: whenever we add/modify the Models we must syncdb right?18:24
mhall119|workyou add Models with syncdb, but it's not smart enough to know how to handle modifications18:25
mhall119|workthere is a separate project, django-south, that lets you automate modifications to tables18:25
mhall119|workbut that's a subject for another lesson18:25
mhall119|workokay, so another very powerful tool Django provides is the concept of ForeignKeys and Many2Many relationships18:27
mhall119|worknot only does it provide for these in your python code, but it handles them in the database as well18:27
mhall119|worksuppose we wanted to add a Course model, that would be a collection of Sessions on a common topic18:28
mhall119|workmuch like this series of lessons18:28
mhall119|workwe would want to link a Session to a Course through a ForeignKey field18:28
mhall119|workif you run "bzr pull -r tag:day2.4" you will get exactly that18:28
mhall119|worknow if you look at class/models.py you will see that we added a Course model that is just a title, start and end dates18:29
mhall119|workand at the bottom of the Session model, you will see a new field named 'course' that is a ForeignKey to this new model18:30
mhall119|workagain, Django will map this field to a python object, in this case it will be our Model class 'Course'18:30
mhall119|workso you can do mycourse = Course(title="Learning Django Week")18:31
mhall119|workmysession.course = mycourse18:31
mhall119|workand again Django handles the mappings between python and the database for you18:31
mhall119|workany questions before we move on?18:32
mhall119|workguess not, okay18:33
mhall119|workso, another common object-oriented paradigm is the notion of inheretance18:34
mhall119|workand it turns out that Django can handle this too18:34
mhall119|workif 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 fields18:34
mhall119|workyou 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 classes18:35
mhall119|worknow, Jono Bacon has this really cool program called Lernid that some of you may have used (or may be using right now)18:36
mhall119|workit basically combines #ubuntu-classroom, #ubuntu-classroom-chat with a web browser, terminal and schedule listing all in one app18:36
mhall119|workit also has the ability to display slides from a downloaded PDF18:37
mhall119|workso, if we wanted to capture the slide URL for a session using Lernid, we can create a subclass of our Session model for this field18:37
mhall119|workand if run "bzr pull -r tag:day2.5" you will see that I did exactly that18:38
mhall119|workwe now have a model called LernidSession that inherits from Session, and adds a URLField for slides18:38
mhall119|workand if you run "python manage.py syncdb" again, you will see it making the new table for this model18:39
mhall119|work< hemanth> QUESTION : can something like mysession.course = Course(title="Learning Django Week"); be achieved18:40
mhall119|work                 ? {inheritance}18:40
mhall119|workthat's not inheritance, that's just creating a new Course instance and assigning it to mysession.course18:40
mhall119|workdid you mean something else?18:40
mhall119|workoh, no, the Session won't inherit the methods of Course18:42
mhall119|workmysession.course will be an instance of Course18:42
mhall119|workso you can do mysession.course.title18:42
mhall119|workthis of mysession.course as just a variable attached to mysession that holds an instance of Course18:42
mhall119|workbut if you did mylernid = LernidSession(title="Lernid Session"), then mylernid would have the fields from both Session and LernidSession18:43
mhall119|workso you could also do: mylernid.course = mysession.course18:44
mhall119|workdoes that make sense?18:44
mhall119|worknow we have our wonderful models, lets go somewhere where we can see them18:45
mhall119|workDjango provides a very powerful Admin application that lets you manage instances of your models18:46
mhall119|workit is located in django.contrib.admin18:46
mhall119|workso 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 of18:46
mhall119|workrunning "bzr pull -r tag:day2.6" will get all of that for you18:47
mhall119|workyou should have a new file under class/admin.py18:47
mhall119|workif you look in there, you can see that we are registering each of our models with the admin application18:48
mhall119|workwe also wired the application to the url '^admin/'18:48
mhall119|workonce 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 created18:49
mhall119|workthen, run "python manage.py runserver" and it should start up Django on localhost18:50
mhall119|workit'll say Django is running on or something similar18:51
mhall119|workthen if you go to it will take you to the login screen for the admin app18:51
mhall119|workthe 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:51
mhall119|workdid everybody get to logged in to the admin?18:52
mhall119|work< hemanth> QUESTION : The current URL, , didn't match any of these.Should i change anything in settings.py ?18:53
mhall119|workyou need /admin/ after the host:port18:53
mhall119|workalright, so once you're in, you will see the "Class" section has our models listed18:54
mhall119|workeach application in your project that registeres models will have it's own section18:54
=== yofel_ is now known as yofel
mhall119|workfrom here you can add/edit/delete models18:55
mhall119|workyou 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 key18:55
mhall119|workgo ahead and create a new Course instance, and then a Class Session instance for that course18:56
mhall119|workyou'll notice while you're doing this that the labels come from the verbose_name attribute of the field18:57
mhall119|workand the help_text for the field is displayed below the widget18:57
=== 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
mhall119|work< hemanth> QUESTION : no such column: class_session.course_id; i had ran syncdb19:00
mhall119|workcan you guys still see me?19:00
mhall119|workokay, we're running over, but I don't think anyone is on right away, so we'll continue19:01
mhall119|workremember how I said that syncdb wasn't smart enough to edit a model's table?19:01
mhall119|workwell, we added Session.course as a ForeignKey after we ran the syncdb to create teh Session table19:01
mhall119|workso we need to clear out our existing table structure, and put the correct one in place19:02
mhall119|workwith django-south, we could just add the one field, but for now we'll just start over19:02
mhall119|workto do that run "python manage.py reset class"19:02
mhall119|workthis will drop all the tables for the "class" application, and rebuild them according to the current model19:02
mhall119|workonce you've done that, you can go back into the admin and add your courses and sessions19:03
mhall119|workno, reset should recreate all the tables that syncdb would create19:04
mhall119|workso, when you create your instances, you will probably notice that they're being displayed as "Session object" or "Course object"19:05
mhall119|workwell that's not very useful19:05
mhall119|workwe want them to identify themselves as something meaningful to us19:05
mhall119|workto do that, we overwrite the __unicode__ method in the Model19:05
mhall119|workif you run "pull -r tag:day2.7" you will see that I do this for Course and Session19:06
mhall119|workI don't need to do it for LernidSession, because it will inherit the __unicode__ implementation from Session19:06
mhall119|worknow when you go back into the Admin, you will see Cources listed by their title, and Sessions listed by their title and teacher19:07
mhall119|workand that concludes (a little late) day 2 of this course19:07
mhall119|worktomorrow we will begin looking at Django Forms, another powerful set of classes that lets us connect users to our Models19:08
mhall119|workagain, you can email me at mhall119@ubuntu.com should you have any questions19:08
mhall119|workthank you all for attending, and I will see you tomorrow19:09
=== dclarke_ is now known as SmartSsa

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!