Join Kevin Skoglund for an in-depth discussion in this video File structure of a Rails application, part of Ruby on Rails 3 Essential Training.
- View Offline
In the last movie we generated a controller and a view and we saw that Rails helpfully put those files into certain folders for us. Before we go further, let's take a look at the structure of our Rails application so that you will also have an understanding of why certain code goes inside certain places in the framework. So I have simply opened up my Finder window to the root of my Rails applications, simple_cms and here's the folders that were created for us. Now the first thing I want you note is there are lot of folders here and there's folders inside those folders. Rails has some very definite ideas about where it wants you to put code.
This is part of the framework. It's a good thing. So you want to learn where things go, so that we can work with the framework instead of working against it. So the first thing is we have this app folder. It is the most important folder in your entire application, because it contains the core of your application code and you are going to spend 95% of your time programming in this app folder. If we open it up we'll see the MVC architecture in place. We have controllers, we have models, and we have views. We also have a folder for helpers.
Helpers are going to be things that help us out in the controllers and views primarily, but also in the models, its helper code. You may also have a fifth folder here called mailers. It's just an empty folder at first, but it's where you would put templates for application to use when sending emails. Those email templates used to be kept in the views folder, but starting with Rails 3, they get their own folder. The important thing will be to make sure that we get the right code into each one of those folders and stick with the MVC architecture. Moving on down the list, we've got the config folder, which is for configurations.
We won't walk through all of these, but you can see we have a file for our application configuration, we have our database configuration, we also have initializers, which is code that we want to run when we first launch the Rails app. We have locales, which is for internationalization, if we need to support different languages, that's built into the framework already. Internationalization is part of rails. And then we have the routes, which we will talk more about, but that's how we decide how different URLs get mapped to different parts of our application, how we send commands into the app.
Next we have config.ru. That's going to be a configuration file for rack-based servers to use. You won't need to edit it. Just leave it alone, leave it right there. It's fine. The db folder is going to be for things concerning our database. Eventually when we learned about database migrations, this is where we are going to store our migration code, things that relate to the database. doc is for documentation. This is where we can put documentation about application. It's also a place where you can put things like to do lists or different notes and things that you want to keep with the application itself.
Now as we will learn later on there are three main ways we can get an external code into our Rails application to use it, code that other people have written, third-party libraries, that kind of thing. One is by using RubyGems and this Gemfile will help us to be able to pull those into our application. The second is by putting them in our lib folder. That's where we can just store them. It's for library files. And then the other one is in our Vendor folder, we have a folder called plug-ins. So those are the three main places that we can put either gems, plug-ins or just general library files, that we either get from somewhere else or that we write ourselves Next we have log folder. This is going to be the folder where we are going to store all the logs that are going to give us information about what's going on inside the application.
It might be errors that are taking place or it might be just general information that we've chosen to log to these log files. We will come back and talk about the public folder in just a moment. The Rakefile is also a file that's used by Rails and you won't need to worry about. README is just a simple text document for you to fill out, sort of describing what is this simple CMS. You can go ahead and just fill that out with some basic information. Script is where scripts are going to be stored use by Rails and you can see that's where this Rails command that we run. It actually is going to use the script that's in that folder. You won't need to put things in there most of the time.
Test is for testing. This is where we are going to put our test code. Testing is something that's a little more advanced, but the idea is that we can write code that make sure that our other code does what we expect it to do and then all of that test code can go inside of this folder. Tmp is a place for Rails to put temporary files that it needs to work with, things that it will create and delete, and we won't need to worry about those at all. We can just let it use those and make use of them. So last of all the one we skipped was the public folder. So I want to come back to that now.
So what is the public folder? The public folder is a place for all of the files and assets that our application is going to need that do not need to be processed by the application framework, right. They are good to go already. They're ready to be sent to the browser. That's different from our application code, which needs processing. The other difference is that the public has access to these files. They can see them if they know the right URL type. They have the ability to see the files that are there. So anything that's in the public folder, you have to assume that the public has some ability to see it.
So soon as the web server says "Hey, I need that image," it can just grab the image and pass it off to the browser. Now the fact that it needs that image is still controlled by the application code, right. The application code decides here's the view that I'm going to construct, right. I am going to pass that back to the browser and in that view there's embedded three images. Well, then the web server says, "Oh, three images, let me go grab those real quick." Boom-boom-boom. It goes to make a quick trick to the public folder and sends those images along, without going back through the whole application framework, which is slower.
Now this really leads us to a discussion of how server requests are actually handled by our Rails application. And that's what we are going to look at in the next movie. So if it's not 100% clear to you, just hang on. We are going to take a closer look at it.
- Understanding MVC (Model View Controller ) architecture
- Routing browser requests through the framework
- Responding to requests with dynamic content
- Defining associations and database relationships
- Creating, reading, updating and deleting records
- Working with forms
- Validating form data
- Reviewing built-in security features
- Authenticating users and managing user access
- Debugging and error handling