=== 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|work | I guess that means it's time to start | 18:00 |
---|---|---|
mhall119|work | can I see a show of hands for who's here? | 18:01 |
mhall119|work | alright, great | 18:02 |
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:03 |
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:04 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
mhall119|work | "Session" will be our model for defining the data we are going to work with for those sessions | 18:11 |
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:13 |
mhall119|work | so if you "bzr pull -r tag:day2.2" you will see the new Meta class in Session | 18:14 |
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:15 |
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:16 |
mhall119|work | run "bzr pull -r tag:day2.3" to get the fields for our model | 18:17 |
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:18 |
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:19 |
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:20 |
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:21 |
mhall119|work | whenever you add new Models, you have to run syncdb again to have Django create the necessary tables | 18:22 |
mhall119|work | any questions so far? | 18:24 |
ClassBot | hemanth asked: whenever we add/modify the Models we must syncdb right? | 18:24 |
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:25 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
mhall119|work | any questions before we move on? | 18:32 |
mhall119|work | guess not, okay | 18:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
mhall119|work | and if you run "python manage.py syncdb" again, you will see it making the new table for this model | 18:39 |
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:40 |
mhall119|work | hemanth? | 18:41 |
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:42 |
mhall119|work | but if you did mylernid = LernidSession(title="Lernid Session"), then mylernid would have the fields from both Session and LernidSession | 18:43 |
mhall119|work | so you could also do: mylernid.course = mysession.course | 18:44 |
mhall119|work | does that make sense? | 18:44 |
mhall119|work | okay | 18:45 |
mhall119|work | now we have our wonderful models, lets go somewhere where we can see them | 18:45 |
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:46 |
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:47 |
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:48 |
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:49 |
mhall119|work | then, run "python manage.py runserver" and it should start up Django on localhost | 18:50 |
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:51 |
mhall119|work | did 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|work | you need /admin/ after the host:port | 18:53 |
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:54 |
=== yofel_ is now known as yofel | ||
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:55 |
mhall119|work | go ahead and create a new Course instance, and then a Class Session instance for that course | 18:56 |
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 | 18: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 syncdb | 19:00 |
mhall119|work | can you guys still see me? | 19:00 |
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:01 |
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:02 |
mhall119|work | once you've done that, you can go back into the admin and add your courses and sessions | 19:03 |
mhall119|work | no, reset should recreate all the tables that syncdb would create | 19:04 |
mhall119|work | sorry | 19:04 |
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:05 |
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:06 |
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:07 |
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:08 |
mhall119|work | thank you all for attending, and I will see you tomorrow | 19:09 |
=== dclarke_ is now known as SmartSsa |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!