Python for Entrepreneurs Transcripts
Chapter: Build web apps with Pyramid: Part 1
Lecture: Project Structure
Login or
purchase this course
to watch this video and the rest of the course contents.
0:03
In order to get started and be effective with Pyramid, it's important to understand the project layout.
0:09
And what files are created and where new ones should be put or where you go and find existing ones for things you want to change.
0:17
Let's take a quick survey what comes out of the starter project scaffold. Now, as we build up a real professional application,
0:24
this structure will get much richer and we'll add on many more concepts and conventions of our own, but they will be framed around this basic skeleton.
0:34
So let's start at the top. At the top we see the "static" folder, and here we have CSS, JavaScript, images,
0:41
basically these are the static files that are just served up directly as files, they are not processed as some kind of action request
0:49
that our Python code is going to handle, we just say here is an image, here is a CSS file and so on.
0:55
There is a special rule for caching inside this folder I believe the default is one hour but of course you probably want to make that higher
1:02
and do some cache busting techniques. Then we have our templates, or what I am going to call views,
1:08
there might be a little confusion on the nomenclature here and the nomenclature that Pyramid uses is somewhat unique to it,
1:15
Pyramid is a MVC, a model view controller-based framework, like Ruby on Rails, like ASP.NET MVC, like many of these.
1:25
So when I speak of the project items, I am going to use the more general MVC terms but as much as I need to corelate that with the Pyramid words
1:34
or folder names or things like that, I'll try to line this up for you. So we have the templates folder,
1:40
and this is where the dynamic HTML pages that are rendered by Pyramid itself go, so for example if I wanted to make a request, go to a database,
1:48
pull back ten items, let's say we are doing a book store, get ten books back, pass that book data off to this template,
1:55
this template will generate the HTML page that has like basically ten rows of whatever, we do to put a book if it's a listing or whatever.
2:03
So these "pt" files, these are chameleon templates and they are in there, in the large MVC world these are called "views", the __init__ file
2:12
this is like your application startup code, there is several methods in here that run right as your app starts up,
2:19
you register the template folder, you register the static folder, you talk about the views and various other setup.
2:25
If you do logging or other configuration, it all happens here, so think of this as your main entry point to your web application.
2:32
Then we have unit tests, your web app scaffold comes with a set of unit tests the very basic but they show you how to write tests,
2:40
so you'll know how to test your own code going forward, they serve very good as starter template ideas
2:46
but they don't really test anything important in the basic code of course.
2:49
Finally, we have things called views, in the MVC world these are controllers, these are the methods that run
2:54
when a request and HTTP request comes into our web app, you'll find one of the methods in this "views" file
3:01
for now, we are going to expand greatly on this later, but for the starter project there is some functions in here,
3:05
and we map URLs to the various functions and then those run, they select a template out of the template folder and pass some data,
3:12
boom, we have a magic dynamic data driven web app. You also see this .egg-info folder and a bunch of stuff under there,
3:20
basically you can ignore this, this is the output from setup.py when you called "setup.py develop", this is the files that put in place here,
3:27
instead of registering and copying this over to some side package, so you need this for your app to run,
3:34
but you can generally and should generally just ignore it. You'll also see your project settings and configurations
3:39
we have the development.ini, which configures how our app runs locally and then production.ini for when we push to production.