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