## Step 3: Basic Configuration

As you can see, Fuel can do basic Controller/View stuff out of the box, but if we want to do much more, we'll need to make some basic configuration changes. Let's start by opening up fuel/app/config/config.php and setting a few things up:

If you have mod_rewrite installed, we can change this value to be an empty string, which will let us remove index.php from our URL's. There is a .htaccess file in public/ which will support this.

Next we need to set up the database configuration, which, for the sake of this tutorial, we'll assume is MySQL. Create your database with your desktop GUI, phpMyAdmin, or etc command line:

Open up fuel/app/config/db.php and set the Fuel::DEVELOPMENT array, like so:

Next, lets enable the orm and auth package by un-commenting the following lines:

This step is only required if you wish to use them - which in this tutorial we will be.

### Optional: Using a Virtual Host

The last step of setup is to create a virtual host. You do not need to do this, but it means you can use a real URL and remove /public/ from your URL's. If you are using Apache, then a simple chunk like this should do the trick:

If this was a live site, we'd be adding the ServerName as "myawesomeblog.com" instead of "local.blog" but this works for our demo. Once you've added "127.0.0.1 local.blog" to your /etc/hosts file you should be ready to go. If you want to skip this step then adjust URL's in this article.

## Step 4: Kick-starting Development

With this basic understanding of how Controllers, Views and Configuration works, you could probably hop into the documentation and get started rather quickly, but to really get going, the best way has to be Scaffolding.

Scaffolding is not a new concept and is best known for its place in the framework Ruby on Rails. It is essentially a very simple way to create code based on a few assumptions through the command line. You want to add, edit and delete an entity which you name and provide fields for. It is done through oil and the sub-command "oil generate scaffold"

So if we want to build a basic blog, we only need to write "$oil g scaffold post title:string summary:varchar[250] body:text". Oil will be very verbose about what it is doing and tell you all the files created: Note: Models generated by scaffolding use the ORM package so make sure it is enabled as described above. You'll see here a model named "post", a migration (more on those later) a controller "posts" and a bunch of views. The fields are all generated based on the arguments provided, which are fieldname:fieldtype[optional-length]. For title, we used ":string" which, as long as you are using MySQL, will alias :varchar[255], but any DB type is supported. With this command run we need to run our migrations. A migration is a series of changes that need to be made to a database. This becomes useful when multiple developers are working on a project, as each developer can add a migration and you can run a single command to make sure your local copy is up to date. No more "missing field' or "table does not exist" errors after pulling the latest development copy! To run this migration, simply type: Now you can view what Oil has made for you by going to http://local.blog/posts If you want to create controllers, models and migrations separately and not all together like this, you can do so easily with oil g controller, oil g migrate, oil g model, etc. ### Templating You may have noticed, in the step above, that Oil created a file: This will be created when you first run a scaffolding command as all views are wrapped with a "template" or "layout" - which is a header and footer wrapping your content. To change from the default design, all you need to do is edit this template, include your own CSS, add a logo and enter whatever metadata you like. When you create new controllers manually, you can extend 'Controller_Template' instead of the usual 'Controller' to have this template wrapped around any Views loaded in the controller. If you wish to use a different template for a controller, you simply change the $template property to something different.

This will use the fuel/app/views/alternative.php view file instead of the usual fuel/app/views/template.php.

### Working with Forms

One of the most important aspects of any application is form submission. This is how data is captured from a user; it could be a login, a comment, a shopping cart checkout, etc. This is all done with HTML normally, but Fuel gives you some helpful methods to make this process a lot easier. They are optional, so if you are an HTML fanatic, then carry on, but to speed things up, read on:

This is a very simple form that will work with both create and edit. For each input, if it can find a match in POST it will use it; otherwise, it will look for the $post variable and input the value (good for editing). The real benefit of these helpers does not come from cleaner syntax as you might think, but in that it allows the framework to programmatically wrap your form. This means Fuel can automatically embed attributes to all forms to make sure data is sending in the right character set and enable CRSF (Cross-Site Request Forgery) automatically. ### Validating your Forms Validation is a simple way to ensure that certain information has been supplied in a form submission in the correct manner. It can match certain patterns, data types or conditions and will help improve the integrity or the data. By default, validation is not used by Scaffolding, because it's complicated to make assumptions about what the developer expects to be held in the data. For this reason the validation is optional but is quite easy to add into your generated controllers or work with from scratch. Lets take a look at how a "Create Post" method may look for our blog: We can see here that we are telling the Validation class - which is autoloaded like all classes) which fields we care about. We are then assigning rules and giving them labels for humans to read. If $val->run() is true, we make a new Model_Post instance using the factory, and send $val->validated() which contains an array of all the submitted data. With that, we can simply save the instance, which uses ORM to do everything for you. If any of the validation rules return false, then $val->run() will fail and we are given an array of errors in \$val->errors() which we can send back to the user. The default template.php looks for a "notice" piece of flashdata (part of the session class) or just normal view data and can output a string or an array, so this works perfectly.

Using your knowledge of validation and form building, you can start to make any Controller based applications you like.

Tasks are similar to controllers, but cannot be accessed via a URL or routed to in any way. Instead, they are run via the "oil refine" sub-command in the terminal. This is great for creating interactive shell scripts that have access to your codebase and makes creating secure cron jobs a breeze.

Some frameworks suggest you use wget, curl or something similar to run a controller to make a cron job, but this can lead to potential security or consistency concerns with cron jobs being run out of time to cause malicious or unexpected results. This way, it is protected from the outside world completely.

For an example of a task, take a look at the provided "robots" task in fuel/app/tasks/robots.php:

To run this jestful task just type "oil r robots" or "oil r robots 'Kill all Mice' " to make the robot say something else.

## Summary

If you followed each step, you'll have installed Fuel, learned where the important files go, configured a basic install to run on Apache with mod_rewrite (other servers work fine too), and created simple controllers and views using forms and validation. With scaffolding available to generate code to pick apart, there should be plenty of code to learn from!

At this point, you should have enough knowledge to play around and create some really simple apps - that is, until Part two of this series, where we will go through the process of creating and extending Base Controllers to create your frontend/backend separation. We'll also review advanced ORM, authentication drivers, and file uploads. Stay tuned!