 So, by now, we've covered most of the essentials of Web2Pie. As for the things we've omitted, well, first off, there are these two special controllers, one called App Admin and one called Static. The idea of App Admin is just a controller included by default when you create a new application which contains administrative pages for managing the database of your application. So, if you want a web interface where you can inspect the database for your application, then it's already provided for you in the form of App Admin. The so-called Static Controller isn't really a controller. There's no Static.py file in your controller's subdirectory. Rather, in your application directory, there's a subdirectory called Static and any files you place in there can be accessed with a URL where the controller specifies a Static. And then where the action normally goes, that's where you put the relative path from that Static directory. The special thing about requests to files in Static is that they bypass the whole usual request, response, lifecycle. There's no request object. There's no controller invoked. There's no models invoked. There's no nothing, basically. So all the code in your application gets skipped over and simply the file itself is served verbatim. And this is useful for certain Static resource files, like, for example, images in your web pages. You'd likely want to place them in a subdirectory of Static. And then any requests for those files will bypass all of the overhead associated normally with a request to Web 2.py. So usually your images, your CSS files, your JavaScript files, those are the sorts of things you place under Static because you just want to serve them verbatim, no questions asked. Do be clear, then, that you don't want to put any sensitive in the Static directory because you make it public and anyone who requests it, there's no authentication or authorization. It just hands over the file to whoever asks for it. In the welcome application and, in fact, any new application you create, which, again, just uses welcome as its template, you'll find this template file in the views directory called layout.html. A common approach with Web 2.py is to start your application off with all your views extending layout.html. If there's anything you don't like in layout.html, you can simply strip it out or modify it. But it's a handy starting point because it includes a lot of the boilerplate, say, in the header that you're going to want to include in your template anyway, like, say, you'll likely want to include jQuery in your pages. And layout.html already does that for you. So for reasons like that, it's handy to start out with layout.html and then simply modify it as you see fit. In the module gluon.tools, there's a class called auth as in authentication and authorization. And the idea of this class is you instantiate it in your model and it creates tables for users. And the auth class also includes some methods and other things for creating common user authentication and authorization UI stuff, like a login menu, where you click login. It presents the form asking for your username and password and you enter it and then the auth class will then handle the processing of that form. So it's basically just this one big convenience for implementing user accounts in your application. And it's quite flexible. So it should suit most needs while handily sparing you some busy work. What Web2Py calls generic views are basically fallback views for cases where you create an action but then don't create a corresponding view for that action. In some cases, Web2Py will fall back and use one of these generic views. And these views are all really simple. So especially in the case of the generic view for HTML, it's not terribly useful. It's really just there as a developer convenience so that in the course of development, you create an action and forget to create a corresponding view. You'll get something a bit prettier than just a generic error page. However, these generic views may represent a security hole because they might have your application accidentally reveal some of its internal state information, which may be sensitive. So in most production deployments of Web2Py, you'll probably want to disable these generic views. URL rewriting refers to a feature whereby the web framework or actually the web server itself modifies the URL of the request. And one reason you might want to do the same Web2Py is that Web2Py, by default, prescribes this heavy-handed URL format, which quite verbosely always has you specify an application, a controller, and then an action. Well, what if you have a website where there aren't separate applications, there's just one? Well, in that case, you want to be able to omit the application from the URLs because it just kind of clots things up and looks ugly. So that would be one reason why you might want to rewrite URLs. When we covered directives in views, we only mentioned include and extend, but there are two we didn't cover, block and super. They aren't terribly complicated, but we'll talk about them in the supplement. Also, there are a good number of DAO features we didn't talk about for performing more interesting kinds of queries. Like you may have noticed, given what we covered, there's no way to express an outer join. It's all inner joins. Well, there is a facility for doing outer joins. It's just a bit convoluted. Also, it is possible to perform subqueries. And then there's other things, like some SQL operators we didn't discuss, like the in operator or the belongs operator and others like those. And in the supplement, we'll also discuss SQL form and SQL table. SQL form is simply a convenience for automatically generating forms given one or more DAO table objects because very often what we do in web applications is we have the user fill in a form where each field corresponds to the column of the table. And from that, we then insert a new row given the values filled in by the user. So SQL form is just a convenience for performing that common task. The SQL table object is another convenience which generates an HTML table given some rows object given a result set from a query. It then renders that as an HTML table. Again, this is just a convenience for a common task. As I just mentioned, it's very common in web applications to take values entered by users into a form and then insert those into a database or to update one or more rows in a database. What we don't want to happen is for the user to enter improper values, like say to provide a number when we're expecting them to provide their email address or specify their name, checking for those kinds of problems is called validation. We should validate field values before actually adding them into the database. Because validation is such a common task, Web2Py has a feature called validators for validating forms more conveniently. Another common need of web applications is the ability to cache frequently used data. And by data, we might mean something retrieved from the database or something that we've generated, like say some amount of HTML we've generated. We don't want to necessarily repeatedly generate the same HTML over and over again, just like we want to avoid having to retrieve the same data over and over again from a database if we can avoid it. So Web2Py includes a handy mechanism for caching. Another common requirement of web applications is internationalization, which refers mainly to the ability to serve the same pages in different languages. And what you wouldn't want to have to do is to have totally separate pages, totally separate views for different languages. So what we want is some mechanism that allows us to plug in different language text into the same view. So Web2Py has such a mechanism, which we'll discuss in the supplement. And finally, there's the issue of deployment, actually setting up a web server with Web2Py and setting up a database and hooking those things all together. So you have a properly functioning deployment of your web application. For the sake of development, generally, you'll just run Web2Py on your local system. And in that case, you can just get away using the inbuilt web server, which is called Rocket, and using SQLite as the data backend. But then in a real production website, you're gonna want to use something more industrial, like Apache and Postgres. That's one possible configuration, but there are many others. And we'll talk a bit more about how to do a proper production deployment in our supplement.