 It's almost impossible to talk about web frameworks in general, so we're going to cover a specific one in this unit called Web2py, which is a framework for Python. Web2py was created in 2007 by a guy named Massimo DiPiero, who created it originally for the purposes of teaching web programming in his university courses. From there it grew into a proper full-fledged framework and is now developed and maintained by the creator Massimo himself and an online community of developers, which is possible because it's released under an open-source license, specifically the lesser GPL version 3. Web2py is now my framework of choice, as I find the API is very well thought out. The only downside to it being that it only supports Python 2 rather than Python 3. Web2py certainly isn't alone among Python projects that have been very slow to adopt Python 3, but hopefully Python 3 support will show up pretty soon, sometime in the next couple years. A unique selling point of Web2py is how easy it is to get up and running. In fact, you could just go to the website, choose the appropriate download for your platform, whether that's Linux, Mac, or Windows, and then unzip the download and inside you'll find an executable. Run that executable and then you'll see this prompt asking you to specify a server IP, a server port, and a password. The server IP has the default value 127.0.0.1, which is a local private IP address just for your local host system. The server port is by default 8000, which is a sensible number. So unless there's some conflict with some other server running on your system, 8000 should be fine. And then the password, you can leave that blank, but you should fill it in, otherwise some features are left disabled unless you have a password for security reasons. Certain features would be dangerous without a proper password on your server, so Web2py will disable them if you don't provide a password. So fill in a password, click start. This will then start the built-in web server, which is included with Web2py called Rocket, which is not a web server you would use in a real production site. It serves its purpose here for demonstration purposes and just getting up and running and playing around with Web2py, but for a real website you would want to use Apache, which of course you can do with Web2py, but we're not going to do it because that's a lot of distracting configuration stuff to go over. In any case, so Rocket, the built-in web server is launched running on the local host address 127.0.0.1 with port 8000. Once the server is running, which should only take a moment, Web2py will then automatically open your browser and take you to the URL 127.0.0.1 on port 8000 with the path welcome slash default slash index, which is just the default example page when we launch Web2py in this manner. Now, something somewhat unusual about Web2py is that it has this concept of applications. In one running instance of Web2py, whether it's using Apache as its web server or Rocket or whatever as its web server, that one instance of Web2py potentially has multiple applications installed and running. And what an application is is just a sort of logically separate site. I mean normally you go to a domain name like Yahoo.com and you think of this just being one site, but potentially at least Web2py allows you to develop separate applications and host them on the same domain. Nothing forces you to do this, of course. And in fact, in most professional web development, you know, you'll create a site for one domain name and it's not really a usual thing to do to have multiple separate sites all under one domain name. So this multi application paradigm is a bit strange, but it's handy if we need it. In any case, if you look in the directory where we have Web2py installed, you'll find a subdirectory called Applications. And then in Applications we have subdirectories each named for the particular applications. So if I have an application named Foo, it'll be in a subdirectory of applications called Foo. And then in each application directory we have a number of subdirectories, most notably one called Controllers, one called Models, and one called Views. So logically the way Web2py is structured is that first again, we have potentially more than one application in each install of Web2py. And then within each application you have some number of Controller Modules. And inside those Controller Modules you have one or more what Web2py calls Actions. And an Action really is just a function. What Web2py calls a Controller is just an ordinary module of Python code and the actions contained within are just ordinary functions. The basic idea is that each incoming request gets processed by one particular action and which action is specified by the URL of the request. And what Web2py calls a Controller is a little deviant from the term as it's used in MVC, a Model View Controller, because in Web2py a Controller is simply just a model that contains some number of actions. It's almost more proper to think of the actions as really being the controllers in terms of the MVC architecture. But Web2py simply chose to call them Actions and the Controller Modules are really just logical groupings of different actions. So if you have a number of related actions it makes sense to place them together in one particular Controller module. So given an incoming request, how does Web2py decide which action to execute to process that request? Well the pattern is simply that looking at the path of the URL first is specified the name of the application and then after a slash is specified the name of the Controller module and then after another slash is specified the name of the particular action function within that Controller module. And after the action name we can put another slash but that's just optional. It doesn't matter if we put one there or not. So this is the structure for URLs which Web2py expects. Though actually it will also accept URLs which only contain an application and a controller or just an application or actually nothing like say just an empty path. And what's going on here is that if you leave out the action then Web2py assumes the default action name index and if the controller is left off as well Web2py assumes the default controller which is itself called default. And finally the application if you leave that off Web2py assumes the application which has been configured as the default. In Web2py's configuration files you can specify that I want this application to be the so called default application. So looking back at the example page which Web2py first presented to us you can see the path in the URL is welcome slash default slash index. So this is the page returned by the action named index in the controller module named default in the application named welcome. The welcome application is simply an example Web2py application that's included with the Web2py download so it's thereby default initially it's configured as the default application. So here if we enter the URL 127.0.0.1 colon 8000 slash with no path just a slash it would take us actually to the same page because welcome is the default application the default controller name is called default and the default action is called index. Another Web2py application that comes installed with Web2py is a special one called admin. If you navigate to admin slash default slash site you'll see this page though actually it will first prompt you for a password because you don't want anyone to access your admin page you only want yourself to be able to access it or people who are authorized because in this admin application we can do anything we want to our install of Web2py we can install and remove applications and actually we can go in and edit the code of any of the applications there's a web interface provided here for looking at the code and actually editing it. This web interface for modifying your code is actually a unique feature of Web2py you of course don't have to use it you can edit your code like you normally would with a text editor but it's kind of handy that this thing exists for one say you're not on your development machine where you don't have your code if you can log in remotely to the admin application you can then effectively change your code from anywhere you have web access. Arguably though the admin application then represents a pretty damn huge security hole if your admin gets compromised then people can do whatever they want and you'd really be totally compromised so you can if you choose disable this admin application the thing you can't do though however is actually remove uninstall the admin application that's why if you look at the screen here the admin application is listed with a little lock icon indicating that you can't either edit this application or delete it because it's a special application. The other applications you'll see included by default the welcome application which already discussed and the examples application those are just regular applications so you can uninstall them if you choose. The examples application is very strangely named because it's actually the code that runs the Web2py site itself the Web2py.org website. Despite the name examples though it doesn't really include examples I would say welcome actually makes a better example application in any case if you look over on the right you'll see where it says new simple application and we fill in the name of an application we want to create and then hit the create button so I'll do that I enter the name thing and hit create that will create an application named thing and take me to the admin page on which I can edit this application you'll see at the top here it lists the name of the module files which constitute our models first DB.py and menu.py and then you can see we have two controller modules there's default.py and admin.py and underneath that in the view section it lists the content of the views directory in our application which we'll talk more about later so again while you can use this page in the admin application to edit your other applications you don't have to it's a little clunky to be honest just the nature of the web browser is not all that ideal for editing code but it is a neat feature to have in some circumstances I would just go into the actual application directory find the files I want to edit open them in a text editor and do it that way so now that we've created this application thing if we navigate to the URL with the path thing slash default slash index we will see this page and lo and behold it looks exactly like the page in the welcome application except it says thing instead of welcome the reason for this is that when we create a new application the welcome application is basically a template simply making a copy of all that and swapping the name of the application to whatever you chose so with our new applications we start off with some basic functionality already functioning like the ability to create a user account for application and then login and also it provides a general template for the pages now if we don't like any of that we can strip it out so we're not beholden to this it's very easy to get rid of and that's to start with more than just a blank page now here in my editor of choice I've opened the controller module called default which is the file default.py in the directory controllers in our new application default.py doesn't start off life totally empty it has a few actions in it including very importantly index in the case of the index action that's one you can edit as you see fit a couple of the others though we shouldn't edit or remove for reasons we'll discuss much later for clarity though we should start with a blank slate so let's create our own separate controller module which we'll call ground control so in the controllers directory we create a file called ground control.py and we'll open up the file and create one simple action which we'll call major Tom the function major Tom note takes no parameters as return a single string hello world so making sure to save the ground control.py file we then go to our browser and navigate to things slash ground control slash major Tom so the action major Tom inside the controller module named ground control inside the application named thing and what do we see well the page just has hello world it just has that text we returned as a string and in the browser if we look at the page source you'll see that this actually isn't really html there's no html tag with no header tag and body tag it's just the text hello world so when we return a string from an action what's returned in the body of the response is just that text verbatim it doesn't even have to be html and most browsers will then render that as a page as best it can which in this case just means rendering it as plain text now let's go back to the ground control module and add in a second function which will call action man this time though will give the function a parameter X again making sure we save the ground control.py module file once we've finished editing it if we now go back to the browser and enter a URL with the path thing slash ground control slash action man web2py will give us a response with this error message because the function action man is actually not a proper action it doesn't constitute as an action because it has a parameter web2py expects action functions to not have any parameters so only the functions you define without parameters in the controller modules only those are actions any other function you define with a parameter it's not an action come to think of it hopefully I haven't confused you by putting action in the name of the function which isn't an action now as you saw our action major Tom returned a string and when an action returns a string the response that comes back is just that string verbatim when an action returns a dictionary however what web2py will then do is generate a response from a view of the same name as the action and views as we'll see are special modules located in the views directory of our application so given a path application name slash controller name slash action name if the action run returns a dictionary then the response will be generated by the corresponding view file with the same name though actually ending in the extension.html however if in the URL path a different extension is appended to the name of the action then the corresponding view will be that with the same name ending in that specified extension so here we list some examples if the URL reads thing slash ground control slash major Tom well that doesn't have any extension specified so the default extension is .html so assuming that the processing action returns a dictionary the response will be rendered by the file found in thing the application directory slash views slash ground control slash major Tom .html likewise if the URL is the same but ends in the extension .html the same view file will still be used to render the response however if the extension is something else like say .xml then the view file should be the one named major Tom .xml and if it's .json it should be major Tom .json or if the URL extension is rss then it's the view file named major Tom .rss now these view files ending in .html or .xml or .json or .rss the contents of these files aren't really what the extension implies a view file ending in .html does not contain straight HTML it's actually the templating language used by Wip2Py so it's actually a mix of HTML and Python code and the idea is that from this HTML and this Python code an HTML response is generated that's why the view ends in .html and the product is supposed to be .html likewise for a view ending in .json the view file itself likely doesn't contain just .json it includes a mix of Python code but from that .json and Python code a .json response is generated how exactly views generate responses is something we'll get to a bit later so now let's sum up the story so far first off a request comes in and it forces the URL to determine which action and which controller and which application does it want to process this request what happens then is that the controller module the entirety of it not just the action function is run it's executed and in the course of the execution that's when the function gets defined that we then have our function object which we can invoke so the action is invoked and when it returns a dictionary it sends it back to the appropriate view the view of the corresponding name to the action the view then generates a response and this is the body of the HTTP response which Web2Py passes along to the web server and the web server sends it back to the user agent