=== MichiSoft is now known as mthalmei === mthalmei is now known as MichiSoft === dholbach_ is now known as dholbach [10:45] hi [13:44] When is the class on django development going to happen that dholbach blogged about? [13:46] !schedule? [13:46] Factoid 'schedule?' not found [13:46] !schedule [13:46] Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases [13:47] Yeah daniel said it was happening today but didn't give times :/ [13:48] https://wiki.ubuntu.com/UbuntuDeveloperWeek [13:49] dholbach, thanks! [14:09] hey, anyone from Italy? === openweek6 is now known as bikedog === MichiSoft is now known as mthalmei === mthalmei is now known as MichiSoft === starcraftman-mob is now known as starcraft-mobile [15:43] y a t'il une disc meeting started [15:52] pas ici === Ursinha is now known as Ursinha-nom [16:00] padu is it meeting started [16:01] I know that 'Building websites with Django' will start at 17.00 UTC === Jonnie_Simpson is now known as JSimpson [16:59] When is the next class??? [17:00] X3MBoy: In about 30 seconds :) [17:00] erm...now i think [17:01] Ok. [17:01] Thx [17:01] „Getting started with Launchpad development“ [17:01] Hello everybody. [17:01] Hello everybody. [17:01] Well, I didn't expect that to appear twice. [17:01] hello [17:02] Hmm. [17:02] Anyway [17:02] hi [17:02] My name's Graham Binns. I'm a member of the Launchpad Bugs development team. [17:02] hai [17:02] hi [17:02] hi [17:02] hello [17:02] I'm going to talk today about getting started with Launchpad development, in the hope that it might make it easier for you guys to contribute patches to scratch your least favourite itches. [17:02] hi [17:02] Hopefully you'll have all completed the instructions at http://dev.launchpad.net/Getting so that you can follow along with this session. If not, you might struggle a bit, but you can always go back once the session is over and follow it through on your own time. [17:03] Note: chatter and questions please in #ubuntu-classroom-chat [17:03] If you've any questions, please shout them out in #ubuntu-classroom-chat and prefix them with QUESTION so that I can see them easier :) [17:03] Okay, so, first things first, we need to find us a bug to fix. For the purposes of this session I've filed a made-up bug on staging for us to fix https://staging.launchpad.net/bugs/422299. I've gone with this because: [17:04] 1) It's fairly simple to fix. 2) It's easy to demonstrate our test-driven development process whilst we fix it, which is why I didn't pick a bug in the UI. 3) There were no really trivial bugs available for us to try this out on :). [17:04] When you're working on fixing a bug in Launchpad, you nearly always want to be doing it in a new branch. [17:05] We try to keep to one bug per branch, because that means that it's much easier to review the patches when they're done (because they're smaller, natch :)) [17:05] So, let's create a branch in which to fix the bug. [17:05] If you've set up the Launchpad development environment properly according to http://dev.launchpad.net/Getting, you should be able to run the following command: [17:05] $ rocketfuel-branch getting-started-with-lp-bug-422299 [17:05] Note that I've appended the bug number to the branch [17:05] so that I can always refer to it if I need to [17:06] but I've also given the branch a useful name to help me remember what it's for if I have to leave it for a while. [17:06] rocketfuel-branch takes a few seconds, so I'll just wait a minute for everyone to catch up. [17:07] (By the way, if anyone has any problems with rocketfuel-get or any other part of this lesson, please come find me afterwards in #launchpad and I'll try to help you out) [17:07] s/-get/-branch/ there, sorry. [17:08] Okay. [17:08] Now, at this point, once you'd decided how to fix the bug [17:08] but - importantly - before you start coding [17:08] you'd ideally have a chat with a member of the Launchpad development team about your intended fix. [17:08] We normally do this either on IRC or on Skype, depending on your preference. [17:09] You can usually find a Launchpad developer in #launchpad-dev on Freenode who'll be available for one of these calls. [17:13] The call gives you a chance to ensure that what you're doing is actually sane. [17:13] For some bugs there's only one possible fix, complex or otherwise. For others there may be many ways to do it, and it's important to pick the right one. [17:13] If your solution is particularly complex or you need to demonstrate *why* you want to do things the way you do, it may help to write some tests to reproduce the bug before you have the call. [17:13] Note that the tests should always fail at this point; [17:13] you shouldn't make any changes to the actual code until you've had the pre-implementation call or chat with an LP developer. [17:13] Okay, so that's the info-dumpy bit of this session over for now :) [17:14] (gmb is having lag issues, please stand by) [17:15] Sorry about that, all. [17:15] I have a rather flaky connection today :) [17:15] As I was saying... [17:16] Under lib/lp you'll find most of the Launchpad code, split up into its applications. [17:16] So, `ls lib/lp` in your new getting-started-with-lp-bug-422299 branch should give you something like this: [17:16] $ ls lib/lp [17:16] answers archiveuploader buildmaster coop registry soyuz [17:16] app blueprints code __init__.py scripts testing [17:16] archivepublisher bugs codehosting __init__.pyc services translations [17:16] Now, we know that we're working in the bugs application, so lets take a look in there to see where to put our tests: [17:17] $ ls lib/lp/bugs [17:17] adapters emailtemplates help model stories windmill [17:17] browser event __init__.py notifications subscribers xmlrpc [17:17] configure.zcml externalbugtracker __init__.pyc pagetests templates [17:17] doc feed interfaces scripts tests [17:18] There are three types of test in Launchpad: doctests, which live in lib/lp/$app/doc; stories, which live in lib/lp/$app/stories and unittests, which live in lib/lp/$app/tests. [17:18] In this case we want to add to an existing doctest, so I'll stick with that for now and we can come back to what the others are for later. [17:18] So, in lib/lp/bugs/doc/ you'll find a file called externalbugtracker-trac.txt. [17:18] This is the test we want to modify, so feel free to open it in your text editor and take a look at line 110, which is where we're going to add our test. [17:19] For the sake of making this quicker, I've already created a diff of the change that I'd make here: http://pastebin.ubuntu.com/263869/plain/ [17:19] You can save that to disk somewhere (e.g. /tmp/diff) and then apply it as a patch using `bzr patch /tmp/diff` in the root of your new Launchpad branch. [17:20] The test we've just added is really simple. [17:20] It passes 'frobnob' to the convertRemoteStatus() method of a Trac instance (which is just an abstraction that lets us talk to an actual Trac server) [17:20] and expects to get "Fix Released" back. [17:21] Of course, it doesn't since we haven't implemented that yet :). [17:21] Once we've written the test, we run it to make sure it fails. [17:21] This part is very important: your tests should always fail first and only after they fail do you write the code to make them pass. [17:21] That means that you can use the tests to build a good spec of how your module / class / function / whatever should behave. [17:22] It also means that, like I said before, you can use the failing tests to demonstrate what your fix will actually change to whoever you have a call with. [17:22] To run this specific test only, we use the `bin/test` command: [17:22] $ bin/test -vvt externalbugtracker-trac.txt [17:23] That might take a short while to run (Launchpad's test suite can be frustratingly slow sometimes, but don't let that put you off; the payoff is worth it) [17:23] The output from which should look something like this: http://pastebin.ubuntu.com/263874/ [17:23] Note the important bit: [17:23] File "lib/lp/bugs/tests/../doc/externalbugtracker-trac.txt", line 111, in externalbugtracker-trac.txt [17:23] Failed example: [17:23] trac.convertRemoteStatus('frobnob').title [17:23] Exception raised: [17:23] Traceback (most recent call last): [17:23] File "/home/graham/canonical/lp-sourcedeps/eggs/zope.testing-3.8.1-py2.4.egg/zope/testing/doctest.py", line 1361, in __run [17:23] compileflags, 1) in test.globs [17:24] File "", line 1, in ? [17:24] File "/home/graham/canonical/lp-branches/lesson/lib/lp/bugs/externalbugtracker/trac.py", line 265, in convertRemoteStatus [17:24] raise UnknownRemoteStatusError(remote_status) [17:24] UnknownRemoteStatusError: frobnob [17:24] This tells us that the test failed, which is exactly what we wanted. [17:24] (Yes, copying and pasting in IRC makes me a bad man.) [17:24] nvertRemoteStatus() raised an UnknownRemoteStatusError instead of giving us back the status we wanted. [17:24] Which was, of course, the 'Fix Released' status. [17:24] At this point, you might want to commit the changes: [17:24] $ bzr commit -m "Added tests for bug 422299." [17:25] Again - I can't emphasise this enough - the fact that your test fails is a Good Thing. If it didn't fail, it wouldn't be a good test, since we know that the bug actually exists in the code. [17:25] Now that we have a test that fails, we want to add some code to make it pass [17:26] We want to add this to lib/lp/bugs/externalbugtracker/trac.py. [17:26] Now, as it happens, I knew that before I started, but you can work it out by looking at the top of the doctest file that we just edited. [17:27] So, open lib/lp/bugs/externalbugtracker/trac.py now and take a look at line 258. We'll add our fix here. [17:27] The fix is really simple, and we can pretty much copy line 255 and alter it to suit our needs. [17:27] We want 'frobnob' to map to 'Fix Released', so we add the following line: [17:28] ('frobnob', BugTaskStatus.FIXRELEASED), [17:28] I'll not go into the nitty-gritty of how status lookups work here, because it's unimportant. [17:28] Suffice it to say that in Trac's case it's a simple pair of values, (remote_status, launchpad_status). [17:29] Here's a diff of that change: http://pastebin.ubuntu.com/263882/ [17:29] Now that we've added a fix for the bug, we run the test again: [17:29] $ bin/test -vvt externalbugtracker-trac.txt [17:29] This time, it should pass without any problems... [17:30] and it does === Traveler is now known as Guest89726 [17:30] http://pastebin.ubuntu.com/263885/ [17:30] So, now we commit our changes: [17:30] $ bzr ci -m "Fixed bug 422299" [17:30] (Note that this is a lame description of the fix; you should use something more descriptive). [17:31] So, we now have a branch that fixes a bug. Hurrah and all that. [17:31] Now we need to get it into the Launchpad tree. [17:31] Launchpad developers use the Launchpad code review system to review Launchpad branches. [17:31] You can't land a branch without having it reviewed first [17:32] This allows us to ensure that code quality stays high [17:32] And it also acts as a sanity check to make sure that the developer hasn't done something unnecessarily odd in their fix. [17:33] So at this point, you need to push your branch to Launchpad using the `bzr push` command: [17:33] $ bzr push [17:33] Once the branch has been pushed up to Launchpad it gets its own page in the Launchpad web interface, which you can look at by running: [17:33] $ bzr lp-open [17:33] This should open the page in your default browser. [17:34] Now that you've fixed the bug and pushed the branch to Launchpad you need to request a review for it. [17:34] To do this, go to the branch page in your browser and click the "Propose for merging into another branch" link. [17:35] This will take you to a page that looks like this: [17:35] http://people.ubuntu.com/~gbinns/propose-merge.png [17:36] In the "Initial comment" box, you need to type a description of the branch. [17:36] For example, for this branch I'd write something like: [17:36] "This branch fixes bug 422299 by making Trac.convertRemoteStatus() map the "frobnob" status to Launchpad's Fix Released status." [17:38] After you've typed in your description, hit the "Propose merge" button and you should see a page that looks something like this: https://code.edge.launchpad.net/~gmb/launchpad/lesson/+merge/11068 [17:38] You then need to head on over to #launchpad-reviews on Freenode and ask if anyone's available to review your branch. [17:38] If there's no-one available at the time, don't worry. [17:39] We have a reviewer schedule: http://dev.launchpad.net/ReviewerSchedule, so someone should take a look at it withing 24 hours. [17:39] The reviewer may ask you to make changes to your branch [17:39] To bring your fix into line with our coding standards [17:40] Or maybe to fix a bug that they've spotted in your fix. [17:40] Once the reviewer has signed off on the changes, they'll submit the branch for merging for you. [17:41] When a branch gets merged, the entire test suite is run against it [17:41] If any of the tests fail [17:41] The reviewer may ask you to help fix them [17:41] But it's likely that someone else will take care of it if you're not around at the time [17:42] And that's about all there is to simple Launchpad development :) [17:42] Are there any questions? Please shout them out in #ubuntu-classroom-chat [17:47] < ahe> QUESTION: When will launchpad be available as a package in the standard distribution? [17:48] ahe: At this point, there aren't any plans for that. We released the code for Launchpad because we wanted to let people help to improve the service, but we've no plans as far as I'm aware to distribute it as a package. [17:52] < Andphe> question: have you planned guys, offer launchpad in another languages than english, example spanish ? [17:53] Andphe: It's something that we've considered and that we would like to do at some point, at least for certain parts of the interface. [17:53] The problem is that launchpad is meant to be a global collaboration tool, and if we translate it wholesale into other languages that automatically means that a certain amount of collaboration will be lost [17:54] For exampel, if a user reads the interface in Spanish and files a bug in Spanish, how am I, an non-Spanish speaker, going to be able to deal with that bug report? [17:54] However, internationalisation would work quite well for the Answers application, and it's already built with that in mind. [17:54] < ahe> QUESTION: Do you deploy launchpad manually or are there some helper scripts or stuff like that to ease the deployment in a production environment? [17:55] It's a combination of the two. [17:55] edge.launchpad.net is deployed by a script every night, as is staging.launchpad.net. [17:55] The production servers are updated manually by our sysadmins at least once per cycle (though it's usually more than that since we discover urgent bugs that need to be fixed). [17:57] < Andphe> question: if answers already support another languages, how can we help to translate it ? [17:58] Andphe: It's built with translation in mind, but I don't know what work needs doing to make it translatable. [17:58] Andphe: Your best bet would be to join the Launchpad Developers mailing list (http://launchpad.net/~launchpad-dev) and post a question about it there. [17:59] I think that's about all we've got time for. [18:00] If you've any further questions, please feel free to join the Launchpad Dev list (above) [18:00] And ask there. [18:00] Everyone's welcome to contribute. [18:00] Thanks very much for your time. [18:00] thanks gmb [18:00] (and hi everybody) [18:01] Hi everybody, my name is Łukasz Czyżykowski. I work for ISD (Infrastructure Systems Development) team at Canonical. Me and my colleague Anthony Lenton (achuni) will be talking about developing web sites with Django. [18:01] that's me. hi, I'm Anthony Lenton and I also work at ISD. [18:01] this talk is going to be generally given by Łukasz. [18:01] I'm going to be here to answer questions, and maybe interrupt Łukasz just to bother. [18:01] For the purpose of this tutorial we'll build simple web application, we'll use most bits of Django. Our app will be partial Twitter/Identi.ca clone. [18:01] All code for this project is accessible at https://launchpad.net/twitbuntu, you can either download it and look at revisions which moves app forward in the same way as this session is planned. [18:02] or only follow irc session as all required code will be presented here [18:02] I assume that everybody is using Jaunty and have Django installed. If you still don't have it: [18:02] $ sudo apt-get install python-django [18:02] will do the trick. [18:03] First step is to create Django project: [18:03] (as usual, or for if you've just arrived, if you have questions, shout them on #ubuntu-classroom-chat) [18:03] $ django-admin startproject twitbuntu [18:03] $ cd twitbuntu [18:04] Project is container for database connection settings, your web server and stuff like that. [18:04] Now twitbuntu contains some basic files: [18:05] - manage.py: you'll use this script to invoke various Django commands on this project, [18:05] - settings.py: here are all settings connected to your project, [18:05] - urls.py: mapping between urls of your application and Python code, either created by you or already existing. [18:05] - __init__.py: which marks this directory as Python package [18:05] Next we'll setup database connection [18:06] Open settings.py file in your favourite text editor. [18:06] For purpose of this tutorial we'll use very simple sqlite database, it holds all of its data in one file and doesn't require any fancy setup. Django can of course utilise other databases, MySQL and PostgreSQL being most popular choices. [18:06] Enter sqlite3 in DATABASE_ENGINE setting. Line should look like that: [18:06] DATABASE_ENGINE = 'sqlite3' [18:06] [18:06] Also set file name in DATABASE_NAME to db.sqlite (it can be whatever you like): [18:06] DATABASE_NAME = 'db.sqlite' [18:07] To test that those settings are correct we'll issue syncdb management command. It creates any missing tables in the database which in our case is exactly what we want to get: [18:07] $ ./manage.py syncdb [18:07] If everything went right you should see bunch of "Creating table" messages and query about creating superuser. We want to be able to administer our own application so it's good to create one. Answer yes to first question and proceed with other questions [18:07] My answers to those questions are: [18:08] Would you like to create one now? (yes/no): yes [18:08] Username (Leave blank to use 'lukasz'): admin [18:08] E-mail address: admin@example.com [18:08] Password: admin [18:08] Password (again): admin [18:08] Email address is not too important at that stage [18:08] later you can configure Django to automatically receive crash reports on that address, but that's something more advanced [18:09] Next bit is to create application, something where you put your code. By design you should separate different site modules into their own applications, that way it's easier to maintain it later and also if you create something which can be usable outside of your project you can share it with others without necessary putting all of your project out there. It's pretty popular in Django community, so it's always good idea to check [18:09] somebody already haven't created something useful. That way you can save yourself reinventing the wheel. [18:10] For this there's startapp command [18:10] $ ./manage.py startapp app [18:10] In this simple case we're calling our application just 'app' [18:11] This creates an 'app' directory in your project. Inside of it there are files created for you by Django. [18:11] - models.py: is where your data model definitions go, [18:11] - views.py: place to hold your views code. [18:12] Maybe some short terms definition here. Django is sort of Model/View/Controller framework (not really according to its creators). Basically it separates all your code into three separate layers and in principle only code from layer above should get access to lower one. [18:12] First layer are models, where data definitions lies. That's the thing you put into models.py file. You define objects your application will manipulate. [18:12] Above that are controllers which in Django are called views. This code responds to requests from users, manipulates the data and sends it to be rendered to the last layer, which is: [18:13] view in standard world, but here those role is taken by templates. [18:13] Next bit is to add this new application to list of installed apps in settings.py, that way Django knows from which parts your application is assembled. [18:14] In settings.py file find variable named INSTALLED_APPS [18:14] Add to the list: 'twitbuntu.app' [18:14] It should look like that: [18:14] INSTALLED_APPS = ( [18:14] 'django.contrib.auth', [18:14] 'django.contrib.contenttypes', [18:14] 'django.contrib.sessions', [18:14] 'django.contrib.sites', [18:14] 'twitbuntu.app', [18:14] ) [18:15] You can see that there are already things here, mostly things giving your project already built functionality [18:15] Names are pretty descriptive so you shouldn't have problem with figuring out what each bit does [18:16] Now we start making actual application. First thing is to create model which will hold user updates. Open file app/models.py [18:17] You define models in Django by defining classes with special attributes. That can be translated by Django into table definitions and create appropriate structures in database. [18:17] For now add following lines to the end of the models.py file: http://paste.ubuntu.com/263851/ [18:17] (btw, bigger chunks of code are on pastebin) [18:17] Now some explanations. You can see that you define model attributes by using data types defined in django.db.models module. Full list of types and options they can take is documented here: http://docs.djangoproject.com/en/dev/ref/models/fields/#ref-models-fields [18:18] ForeignKey bit links our model with User model supplied by Django [18:18] that way we can have multiple users having their updated on our site [18:19] Another bit of magic is auto_now_add setting of the DateTimeFiled, makes that whenever we create new instance of this model this field will be set to current date and time. That way we don't have to worry about that. There's also auto_now option which sets such field to now whenever instance is modified. [18:19] class Meta bit is place for settings for whole model. In this case we are saying that whenever we'll get list of updates we want them to be ordered by create_at field in ascending order (by default order is descending, and '-' means reversing that order). [18:20] Now we have to synchronise data definition in models.py with what is in database. For that we'll use already known command: syncdb [18:20] $ ./manage.py syncdb [18:20] You should get following output: [18:20] Creating table app_update [18:20] Installing index for app.Update model [18:20] Great thing about Python is it's interactive shell. You can easily use it with Django. [18:20] You start it by [18:20] $ ./manage.py shell [18:21] This runs interactive shell configured to work with your project. From here we can play with our models and create some updates. [18:21] >>> from django.contrib.auth.models import User [18:21] >>> admin = User.objects.get(username='admin') [18:21] Here 'admin' is whatever you've chosen when asked for admin username. [18:22] First thing is to get hold to our admin user, because every update belongs to someone. You can see that we used 'objects' attribute of model class. [18:22] >>> from twitbuntu.app.models import Update [18:22] >>> update = Update(owner=admin, status="This is first status update") [18:22] At that point we have instance of the Update model, but it's not saved in the database [18:23] you can see that by checking update.id attribute [18:23] Currently it's None [18:23] >>> update.save() [18:24] Now, when you saved it in database it has id [18:24] >>> update.id [18:24] 1 [18:24] That's only one of many ways to create instances of the models, this one is the easiest one. [18:24] You can check that update.created_at was set properly to current date: [18:24] >>> update.created_at [18:24] datetime.datetime(2009, 9, 2, 12, 23, 58, 659426) [18:25] You can also see that you get back nice, Python datetime object instead of having to process whatever database returned for that field. [18:25] When we have some data in the database there's time to somehow display it to the user. [18:25] First bit for a view to work is to tell Django for which url such view should respond to. For that we have to modify urls.py file. [18:25] Open it and add following line just under line with 'patterns' in it, so whole bit should look like that: [18:25] urlpatterns = patterns('', [18:25] (r'^$', 'twitbuntu.app.views.home'), [18:25] ) [18:26] First bit there is regular expression for which this view will respond, in our case this is empty string (^ means beginning of the string and $ means end, so there's nothing in it), second bit is name of the function which will be called. [18:26] Now go to app/views.py file. Here all code responsible for responding to users' requests will live. [18:26] First bit is to import required bit from Django: [18:26] from django.http import HttpResponse [18:26] Now we can define our (very simple) view function: [18:26] def home(request): [18:26] return HttpResponse("Hello from Django") [18:27] As you can see every view function has at least one argument, which is request object, which contains lots of useful information about request, but for our simple example we'll not use it for now. [18:27] After that we can start our app and check if everything is correct, to do that run: [18:27] $ ./manage.py runserver [18:28] If everything went ok you should see following output [18:28] Validating models... [18:28] 0 errors found [18:28] [18:28] Django version 1.0.2 final, using settings 'twitbuntu.settings' [18:28] Development server is running at http://127.0.0.1:8000/ [18:28] Quit the server with CONTROL-C. [18:29] As you can see Django first checks if model definitions are correct and then starts our application. You can access it by going to http://127.0.0.1:8000/ in your browser of choice. What you should see is "Hello from Django" text. [18:29] It would be nice to be able to log in to our own application, fortunately Django already has required pieces inside and only thing left for us is to hook them up. [18:29] Everything else is already set up when we first used syncdb command. [18:29] Add following two lines to the list of urls: [18:30] (r'^accounts/login/$', 'django.contrib.auth.views.login'), [18:30] (r'^accounts/logout/$', 'django.contrib.auth.views.logout'), [18:31] Next bit is to create template directory and enter it's location in settings.py file: [18:31] $ mkdir templates [18:31] In settings.py file find TEMPLATE_DIRS setting: [18:31] import os [18:31] TEMPLATE_DIRS = ( [18:31] os.path.join(os.path.dirname(__file__), 'templates'), [18:31] ) [18:31] This will ensure that Django can always find the template directory even if current working directory is not the one containing application (for example when run from Apache web server). [18:32] Next is to create registration dir in templates directory and put there login.html file with following content: http://paste.ubuntu.com/263833/ [18:32] Last bit is to set up LOGIN_REDIRECT_URL in settings.py to '/': [18:32] LOGIN_REDIRECT_URL = '/' [18:32] That way after login user will be redirected to '/' url instead of default '/accounts/profile' which we don't have. [18:33] Now getting to http://127.0.0.1:8000/accounts/login should present you the login form and you should be able to log in to application. [18:33] Now when we can login it's time to use that information in our views. [18:34] Django provides very convenient way of accessing logged in user by adding 'user' attribute to request object. It's either model instance representing logged in user or instance of AnonymousUser class which have same interface as model. Easiest way to distinguish those two is by using .is_authenticated() method on it. [18:34] Modify our home view function so it looks like that: http://paste.ubuntu.com/263835/ [18:35] That way logged in users will be greeted and anonymous users will be sent to login form. You should see "Hello username" at http://127.0.0.1:8000/ [18:35] Using that we can restrict access to our application. But it would be very repetitive having to enter same if statement in every function you want to protect, so there is more convenient of doing the same thing. [18:35] Add following line to the top of the views.py file: [18:35] from django.contrib.auth.decorators import login_required [18:35] This decorator does exactly what we have done manually but it's less code which doesn't hides what this view is doing, now we can shorten it to: http://paste.ubuntu.com/263836/ [18:36] Test view in your browser, nothing should have changed. [18:37] Now when we have reliable way of getting to the user instance we can return all user's updates. [18:37] When designing update model we have used ForeignKey type, this creates connection between two models. Later when we've created updates we used user instance as value of this attribute. That's one way of accessing this data (every update has owner attribute). Due to usage of ForeignKey pointing to User model every instance of it got also update_set attribute which contains every update which is assigned to this user. [18:37] Clean way of getting all user updates is: [18:37] >>> admin.update_set.all() [18:37] [] [18:38] But we can also get to the same information from Update model: [18:38] >>> Update.objects.filter(owner=admin) [18:38] (btw, those are only examples, you don't have to type them) [18:38] Both of those will return the same data, only that first way is cleaner IMHO. [18:38] That's just simple example of a way to get data from the database. You have far greater power over that aspect of your application but as time is short for us I don't get much deeper into that aspect. [18:39] Now when we know how to get to necessary data we can send it to the browser by modifying home function: http://paste.ubuntu.com/263837/ [18:39] Here we set the content type of the response to text/plain so we can see angle brackets in the output, without that, by default, browser would hide it. [18:39] Now, when we have data we can work on dressing it up a little bit. For that we'll use templates. [18:39] Templates in Django have it's own syntax, it's really simple as it was designed to be used by designers, people not used to programming languages. [18:40] We already have templates configured due to requirements of auth system, so it will be very easy to get started. [18:40] First we need some template we can use. Create file template/home.html and put following content in it: http://paste.ubuntu.com/263839/ [18:40] Every tag in Django templates language is contained between {% %} elements and also ending of every opening thing is done by adding end(thing) to the end (like endfor in that case). [18:40] To output content of the variable we're using {{ }} syntax. Also we can use something called filters by using | to pass value through the named filter. We're using that to format date to nice text description of time passed. [18:41] That's template, now let's write view code to use it.. [18:41] There's very convenient function when using templates in views: render_to_response [18:41] add following line to the top of the view.py file [18:41] from django.shortcuts import render_to_response [18:42] This function takes two arguments: name of the template to render (usually it's file name) and dictionary of arguments to pass to template. Having this in mind our home view looks like that: http://paste.ubuntu.com/263840/ [18:42] Now running $ ./manage.py runserver you can see that page in the browser has proper title [18:43] It would be really nice to be able to add status updates from the web page. For that we need a form. There are couple ways of doing that in Django, but we'll show a way which is most useful for forms which are used to create/modify instances of the models. [18:43] By convention form definitions goes to forms.py file in your app directory. Put following bits in there: http://paste.ubuntu.com/263841/ [18:43] This is very simple form which has only one field in it. [18:43] Now in views.py we need to instantiate this form and pass it to the template. After modifications this file should look like this: http://paste.ubuntu.com/263842/ [18:43] Last bit is to display this form in template. Add this bit just after tag: [18:44]

[18:44] [18:44] {{ form }} [18:44] [18:44]

[18:44] [18:44] Now when we have form properly displayed it would be useful to actually create updates based on the data entered by the user. That requires little bit of work inside our home view. Fortunately this is pretty straightforward to do: http://paste.ubuntu.com/263843/ [18:44] First thing is to check weather we're processing POST or GET request, if POST that means that user pressed 'Update' button on our form and we can start processing submitted data. [18:44] All POST data is conveniently gathered by Django in a dictionary in request.POST. For this case it's not really critical to know what exactly is send, UpdateForm will handle that. Bit with instance= is to automatically set update owner, without that form would not be valid and nothing would be saved in the database. [18:45] Checking if form is valid is very simple, just invoke .is_valid() method on it. If True is returned then we're saving the form to the database, which returns Update instance. It's not really needed anywhere but I wanted to show you that you can do something with it. [18:45] Last bit is to create empty form, so that Status field will be clear, ready for next update. [18:45] If you try to send update without any content you'll see that there's an error message displayed 'This field is required'. All of that is automatically handled by forms machinery. [18:45] It's nice to be able to see our own status updates but currently it's only viewable by logged user. [18:46] To implement this feature we'll start by adding new entry in urls.py. Add following entry there: [18:46] (r'^(?P\w+)$', 'twitbuntu.app.views.user'), [18:46] This bit (?P) is python extension to regular expression, it names a bit matched string. Using this name will enable us to write pretty convenient view function in views.py [18:46] First we'll import very convenient shortcut function: get_object_or_404 which gets you model instance if it exists in database or returns 404 Page not found page if such object doesn't exist. [18:47] Then add user function as shown here: http://paste.ubuntu.com/263844/ [18:48] Last bit is to create 'user.html' template which will display this data properly. [18:48] Quickly doing this yields something like that: http://paste.ubuntu.com/263845/ [18:48] Now you can go to http://127.0.0.1/username and see your updates. [18:49] (substitute username with the one you've chosen) [18:49] It's all nice with templates but as you have noticed there are common things in both of our templates. We now have two of them but imagine project with tenths of templates, making change to some common thing would be really painful in such situation. [18:49] Fortunately Django is designed to help in this area too. Feature we're talking about now is templates inheritance. Idea is that you can have base template which defines holes to be filled in by the more specific templates. [18:50] Those holes are named blocks in Django. You define them like that: [18:50] {% block some_block %} [18:50] Block content [18:50] {% endblock %} [18:50] When in template which inherits form such base template you provide data to such block it will replace anything defined before, but if you omit that block default data would be rendered to the end user. [18:50] We'll start by defining our base template in templates/base.html file: http://paste.ubuntu.com/263846/ [18:50] This has some styling introduced, so our app will not look so ugly (not that improvement is dramatic ;D). [18:50]