Like any framework, Web2py has a learning curve.
I’m not talking about the time it takes to master the framework, but the time it takes to start making progress on what you really want to do, which is develop the site. In Web2py, that means being able to create a model, create a controller and get data from a model, and link that controller to a view that displays that data in some useful way.
Models
Models aren’t bad in Web2py. I recommend creating them manually, by typing the code into the model file, rather than using the wizard. Later, when you understand enough about Web2py to understand everything the wizard generates, you can speed things up by using the wizard.
The Web2py Book has some examples in Chapter 3, and a few more in Chapter 6, but there isn’t what I’d call a dedicated section listing everything that can go into a model. Toward the end of Chapter 7 is a list of validators that can be used on models to let forms know constraints on values (e.g. this field must be only letters and numbers).
So it helps to have some experience with databases already, so you know what’s possible, and then can search to see how Web2py does that.
Models And Google App Engine
Worth special mention here is that if you, like me, are targeting Google App Engine, you should understand that you will not be developing models in the same way as if you were targeting an SQL backend database. In particular, many-to-many relationships are inefficient on Google App Engine and don’t scale well.
I’ll be going into more detail on how to handle this when I get to that point in my application, but right now it looks very much like you can start building models the same way you would for SQL. Create a model to represent the relationship, and use references to link it to the other two tables. Later on, we’ll denormalize this for efficiency.
Again, more on the details of this when I get to that point.
Controllers
The purpose of a controller in Web2py is to get data from a model and present that data to a view in an appropriate fashion. This might mean doing some processing on the data first, but doesn’t have to.
In Web2py, every method on a controller becomes, effectively, a page that can be loaded in your web application. For example, if the controller named contest has a method named list, then going to /application/contest/list will execute that method on that controller. This mapping is the default for Web2py (we’ll talk later about how to change the URL to controller mapping).
The return from a controller method is a dictionary that gets passed to the view. The elements of that dictionary become available to the view code for use in displaying the HTML for the page.
Views
By default, every controller method will use the default view, unless a view that is named appropriately is found. For example, the contest controller above had a list method. If I create a view called list.html inside a directory named contest, then /contest/list.html will automatically be used as the view for that controller method.
This mapping is also automatic. For speed of development, it’s a nice feature. You don’t have to tell the controller what view to use (but you can if you want to), Web2py picks the right one for you.
There’s a ton of stuff you can do in views. It’s a web application, after all, and a lot of the action happens in the view. I highly recommend you understand and use the HTML shortcuts available.
For example, using {{=A(“click me”,URL(request.application,’contest’,’list’))}} will put on the web page a link to /application/contest/list. You could just put that link in yourself, but I’m pretty sure the A shortcut will honor any changes you’ve made to the URL to controller mapping. So you could change your mapping and not need to change the links in the views.
The Round Trip
When you can create a model, create a controller, and create a simple view for that controller, you’re ready to start developing your site. Sure, there will be a lot that you’ll still need to learn, but that’s the minimum needed to actually get started generating pages for your site.
Plus, with that knowledge you can have, at all times, a working site in which to test new changes. As soon as you create a new model and controller, you can test that controller using the default view immediately. The default view displays the data passed to it, so you can debug the controller using it. Once you’re satisfied the controller is passing the right info, you can write the view to display it in the way you really want it displayed.
Making the round trip quick for each new feature is a big plus for me, and matches how I like to do development. If I’m writing too much code without being able to test it, I start to get nervous, and I know that my eventual debugging time is going to be higher.