Using Web2py

As promised in the GAE post, here is part 1 of using JSONRPC calls on GAE. I originally intended to write more of a how-to, but now that I’m halfway through, this seems like it should be it’s own post, and I’ll write a how-to part later.

If you’re reading this blog, you probably know how to write Pyjamas apps, but you might not know about web2py, and why or how to use it. I will give a quick overview on how web2py works in the 2nd half of this post, but if you want to just know about using web2py with Pyjamas, or deploying to GAE (on windows), skip to the next post.

I want to start out with a warning. You MUST be careful if you plan to develop an app on GAE. Let’s say hypothetically you have an idea for a business using webapps. You start out with no money and no users. GAE looks really appealing because you can get reliable hosting for free. A few months later you’ve grown and you’re ready to move to your own server. This is where you run into issues. All the server code was written for GAE. If you were good and your code is clean, you can copy several large chunks of code directly over to your new server, but interfaces for things like JSON calls, and interfaces to your database will all need to be rewritten. If you look around, you can find a lot of talk about “portability” and “lock in” and ways to get around this issue. It’s definately a hot topic when it comes to using GAE.

Lock in only happens if you aren’t careful up front. You don’t have to develop using GAE directly, instead I suggest using a web application framework, and build your code on top of that. At the very least, this will protect your code. I’m working on a small game, so I haven’t looked at all into moving database info, but this is something you might want to research. Worst case, you could write a web app to print out all your db info on a web page in a format that you can import to your new server. If anyone knows any good ways to move databases, feel free to leave a comment!

Back to frameworks. There are a couple frameworks available that support GAE. The two most popular are web2py and django. From what I read, neither framework is clearly better – each has its own strenths. It’s more about finding a framework that fits your needs more. For hobbyists, I’d recommend web2py. Web2py supports quicker development. A lot of people say it’s more intuitive and you can be more productive. I feel it aligns better with the Python philosophy. Django has it’s own strengths though. It gives you more control as a developer. Sometimes you’ll want that extra control, it’s really up to you.

If you’ve decided to go with web2py, or even if you didn’t, here is a quick overview of how it works from my non-SW perspective. There are 4 areas I heavily use inside each of my applications – model, controller, view, and the static dir. With that in mind, I want to start with the web2py URLs which take on the form of http://domain/application/controller/function (where function is closely related to view). You also have a static directory which can be accessed using http://domain/application/static/. The static dir is where you’ll have website images, Pyjamas apps, and other static files. There are some defaults setup so if someone visits http://domain/ your server will load something, but most URLs will take on the form http://domain/application/controller/function.

So what do controllers and functions do, and how are they related to views? Well you have a “controllers” folder in your application’s directory which is full of controller scripts made up of several functions. If someone visits http://domain/application/game/loadGame the server will call the game.py file in your controllers directory and run the loadGame() function in that file.

This leads to views. Some functions will be used to handle forms, or handle JSON calls, but your most important functions will return a dict(). When you return a dictionary, it is really returning a reference to the view with the same name as the function. Let’s say this loadGame() function returns a dictionary. In your views directory there should be a html file game/loadGame.html. This is what the server sends users when they visit http://domain/application/game/loadGame.

This views page will probably include links to js. files, images and other static files. This is the 3rd area, the static dir. When you have static files, you will host them here.

There’s one last area – models. The models area has the setup for any databases you’re using, and the setup for other things like the JSONRPC interface. When I tried adding users and storing high scores, I was using this file a lot.

So that’s web2py in a nutshell.

This entry was posted in Frameworks and tagged by Charles Law. Bookmark the permalink.

About Charles Law

Charles started out in Systems Engineering, designing algorithms, but became a programmer once discovering Python's clean syntax. He has experience using many popular products and services in production environments including web2py, uwsgi, AWS, and OpenShift, as well as experience setting up front-ends in Javascript/Python. He tends to cover his experiences, and notes, from setting up servers, and talks about his experiments with different front-end tools.

One thought on “Using Web2py

  1. Thanks man! I’m just beginning to get an overview of all this web stuff, and high level intros like this one really help. Looking forward to the how to part, though ;)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>