{"id":855,"date":"2013-06-30T23:54:07","date_gmt":"2013-06-30T22:54:07","guid":{"rendered":"http:\/\/fragile.org.uk\/?p=855"},"modified":"2013-06-30T23:54:07","modified_gmt":"2013-06-30T22:54:07","slug":"twitter-clone-tutorial-in-web2py-part-3-the-wall-and-search-pages","status":"publish","type":"post","link":"https:\/\/fragile.org.uk\/index.php\/2013\/06\/30\/twitter-clone-tutorial-in-web2py-part-3-the-wall-and-search-pages\/","title":{"rendered":"Twitter Clone Tutorial in Web2py Part 3 – The Wall and Search Pages"},"content":{"rendered":"

Welcome to my getting started with Web2py tutorial.<\/p>\n

This tutorial assumes very little on the part of the reader, some knowledge of a programming language will certainly help, but if not don\u2019t worry. I\u2019ll take you from installation through to v1 of your application.<\/p>\n

If you don\u2019t want to copy from the tutorial, the full source is hosted on github<\/a>.<\/p>\n

Last time we created the Models as well as the Controller and View for the home page. The next page to look at is the Wall.\u00a0The Wall is specific to a given user and contains their profile details as well as their weet history.<\/p>\n

\"Wall_reduced\"<\/a><\/p>\n

As before we start with in the default.py Controller, add the following method to manage the behaviour for the wall.<\/p>\n

# show user's wall, showing profile and posts\ndef wall():\n\u00a0\u00a0\u00a0#Determine which user's wall is to be displayed\n\u00a0\u00a0\u00a0user = db.auth_user(request.args(0) or me)\n\u00a0\u00a0\u00a0#If user is invalid, return to the home page\n\u00a0\u00a0\u00a0if not user:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0redirect(URL('home'))\n\u00a0\u00a0\u00a0weets = db(db.weets.posted_by==user.id).select(orderby=~db.weets.posted_on,limitby=(0,100))\n\u00a0\u00a0\u00a0return locals()<\/pre>\n
The first thing to do is determine whose wall it is that we need to display. The line responsible is worth a closer look.<\/p>\n
user = db.auth_user(request.args(0) or me)<\/pre>\n
We have already seen db used as a means to access the database but we have not yet come across \u2018request\u2019. Request is an object available to all Controller actions and provide details of the http request that instigated the Controller action being called.<\/p>\n
In this case we check the first (technically the zeroth) argument of the request. An argument is best described by example<\/p>\n
http:\/\/127.0.0.1:8000\/witter\/default\/wall\/myargument\/myotherargument\/<\/pre>\n
In this specific instance the argument denotes the user id and so the line in question checks if a user id has been specified, if not it assumes that the requester are themselves logged in and trying to access their own wall. If neither case is true then the browser is redirected to the home page.<\/p>\n
After that we pull out all the weets for the given user and return local variables, which are then made available to the View.<\/p>\n
We will need a new View file called default\/wall.html. As before you can create it via the application admin page.<\/p>\n
Replace the default code with :-<\/p>\n
{{extend 'layout.html'}}\n<h2>Profile<\/h2>\n{{=crud.read(db.auth_user,user)}}\n<h2>Messages<\/h2>\n{{for weet in weets:}}\n
\n
{{=name_of(weet.posted_by)}} on {{=weet.posted_on}}:<\/h3>\n{{=MARKMIN(weet.body)}}\n<\/div>\n{{pass}}<\/pre>\n
We\u2019ve met crud before, it provides a nice high level abstraction to access database information, in this instance we are using it to pull the profile information about the user. The next section loops through all the weets generated in the Controller and presents them in chronological order – this very much the same logic as we saw on the home page. You can a look for yourself at http:\/\/127.0.0.1:8000\/witter\/default\/wall or just navigate there from the Witter home page using the navigation bar at the top.<\/p>\n
Search<\/h2>\n
For the grand finale let’s look at search.<\/p>\n
The purpose of this page is to allow a user to search for their friends and then follow them. In some senses it is the simplest of the pages, but as we shall see it contains some interesting functionality behind the scenes.<\/p>\n
Firstly, let\u2019s take a look at the Controller, add the following to default.py<\/p>\n
# a page for searching for other users\n@auth.requires_login()\ndef search():\n\u00a0\u00a0\u00a0form = SQLFORM.factory(Field('name',requires=IS_NOT_EMPTY()))\n\u00a0\u00a0\u00a0if form.accepts(request):\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0tokens = form.vars.name.split()\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0query = reduce(lambda a,b:a&b,\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0[db.auth_user.first_name.contains(k)|db.auth_user.last_name.contains(k) \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0for k in tokens])\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0people = db(query).select(orderby=db.auth_user.first_name|db.auth_user.last_name,left=db.followers.on(db.followers.followee==db.auth_user.id))\n\u00a0\u00a0\u00a0else:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0people = []\n\u00a0\u00a0\u00a0return locals()<\/pre>\n
The first thing we do is create the search form, we do this like so<\/p>\n
SQLFORM.factory(Field('name',requires=IS_NOT_EMPTY()))<\/pre>\n
The SQLFORM.factory can be used to generate a from an existing database table, or, as in this case can be used to generate a form from scratch. The form is very simple and takes a single input \u2018name\u2019.<\/p>\n
The rest of the Controller handles the action once the input has been received \u00a0– this is what the follow is checking for:-<\/p>\n
if form.accepts(request):<\/pre>\n
The remaining code searches for the the search terms amongst other users registered in witter and plugs them into \u2018people\u2019, it also determines which of those people the user already follows – the View is going to rely on this follower information.<\/p>\n
The Search View<\/h2>\n
So far so good, now let\u2019s take a look at the View, you’ll need to create a file called default\/search.html under the Views section. Replace the default code with:-<\/p>\n
{{extend 'layout.html'}}\n<h2>Search for people to follow<\/h2>\n{{=form}}\n\n{{if people:}}\n<h3>Results<\/h3>\n\n{{for user in people:}}\n
\n
{{=A(name_of(user.auth_user), _href=URL('wall',args=user.auth_user.id))}}<\/div>\n
\n{{if user.followers.followee:}}\nUnfollow\n{{else:}}\nFollow\n{{pass}}\n<\/div>\n<\/div>\n{{pass}}\n{{pass}}<\/pre>\n
Much of this will now be familiar – we pull in the standard template, then the form and then iterate over the \u2018people\u2019 (if any) returned by the Controller. Where it get\u2019s interesting is the button definitions.<\/p>\n
Firstly we check if the searched for user is already being followed by the search, this means the button can offer to follow unfollowed witterers and unfollow the followed. So far so good, but what does this do?<\/p>\n
<button onclick=\"ajax('{{=URL('follow',args=('follow',user.auth_user.id))}}',[],null);$(this).parent().html('Followed')\">Follow<\/button><\/pre>\n
Before I can answer that I need to explain about AJAX. AJAX stands for Asynchronous JavaScript and XML, but this name is largely misleading since it needn\u2019t be asynchronous and needn\u2019t use XML. In short AJAX is a technique for creating dynamic web pages, it allows pages to be updated without needing to reload the entire page, and it does this by exchanging small amounts of information with the server behind the scenes.<\/p>\n
Strictly speaking I could have passed on using AJAX in this tutorial, but it is a really useful technique a very simple to implement.<\/p>\n
In layman\u2019s terms the button definition says, when the button is clicked make a poke to another Controller action called \u2018follow\u2019 and send the arguments \u2018follow\u2019 and the user id. Once this is done replace the button (which read \u2018Follow\u2019) to be some text that read \u2018Followed\u2019.<\/p>\n
A final note about the search View is the use of the css classes ‘row’ and ‘span’. These are provided by Bootstrap<\/a> which is a a popular front end frame work. Bootstrap is not part of Web2py but Web2py does support it out of the box. In this tutorial I’ve deliberately avoided focusing on the look and feel of the app, but Bootstrap provides all the tools necessary to create an attractive web application.<\/p>\n
AJAX Callback<\/h2>\n
And that’s it for the , however, what about the follow action in the Controller? We\u2019ve not implemented that yet. Here goes, add the following to the default.py Controller:-<\/p>\n
# this is the Ajax callback\n@auth.requires_login()\ndef follow():\n\u00a0\u00a0\u00a0if request.env.request_method!='POST': raise HTTP(400)\n\u00a0\u00a0\u00a0if request.args(0) =='follow' and not db.followers(follower=me,followee=request.args(1)):\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0# insert a new friendship request\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0db.followers.insert(follower=me,followee=request.args(1))\n\u00a0\u00a0\u00a0elif request.args(0)=='unfollow':\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0# delete a previous friendship request\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0db(db.followers.follower==me)(db.followers.followee==request.args(1)).delete()<\/pre>\n
The most interesting line is the first one.<\/p>\n
if request.env.request_method!='POST': raise HTTP(400)<\/pre>\n
When a browser makes a request to read a web page it uses an HTTP method called GET, this is exactly what you do everytime you point your browser at Google. There are however other HTTP methods, POST being one of them, POST is used to transmit that is expected to change the state of the application. The AJAX call that we initiate in the search,html View is a POST request.<\/p>\n
Since this Controller action is there solely to support AJAX calls from search.html, it does not expect to handle HTTP GET requests and rejects them. You can try this for yourself by trying to View\u00a0http:\/\/127.0.0.1:8000\/witter\/default\/follow<\/a>\u00a0which should result in a blank page and a error message complaining of a \u2018bad request\u2019.<\/p>\n
\"Search\"<\/a><\/p>\n
Right so there we have it – all pages are complete, in order to try out the search and folllow\/unfollow functionality you\u2019ll need to register to extra users and have them follow each other.\u00a0Be sure to notice that it is not necessary to refresh the search page every time to make a follow\/unfollow request.<\/p>\n
So in conclusion what have we achieved?<\/p>\n
We created a new web2py application called Witter, created three pages (and an AJAX method) supporting a home page, a user wall and a user search and all backed by a database that will persist the data over time.<\/p>\n
Are we done?<\/h2>\n
Well perhaps, I certainly am.<\/p>\n
This tutorial has taken you from nothing at all to a functioning web2py application, that can be extended as you please.<\/p>\n
If you are searching for ideas, you might want to move the search functionality into the home page and extend it so that search covers all weets (much like Twitter does). The UI could certainly do with a spruce up (and there are plenty of CSS tutorials out there) and as a final task you could put the thing live, gain awesome traction (due to your custom tweaks) and take over the social media world.<\/p>\n
Feedback on this tutorial much appreciated, I’ll leave you with some useful links.<\/p>\n