If you want to send flash messages without a package like Sweet Alert, you can reference the laravel docs:
flash messages
In your controller, you would do something like:
session()->flash('status', 'Task was successful!');
The session() method is available globally to the controller and the views. In this example, ‘status’ is the key and ‘Task was successful is the value.’
Then in your view, you would access it like so:
@if(session()->has('status')) {{ session('status') }}
@endif
Play around with that in your test controller and test index view, you will see how it works. You can then style the output in a bootstrap alert, if you wanted to go in that direction.
Ok, so now we’re ready to move on to making a model.
Model
We going to start by creating a model that won’t actually get used on your eventual site. We’re building it as a prototype that we can refer to.
Without getting into a long technical explanation of what the Model is in terms of the MVC pattern, which would have no useful purpose here, let’s talk about it in practical terms of Laravel. The short version is that the model is responsible for interacting with the database.
We already have the User model that Laravel provided us with, so we can store users in the database, among other things. Our other models will tend to be less complicated because we don’t typically have to encrypt the data, like we do when we’re dealing with passwords.
We’re not so concerned right now about how useful our model is, we’re more concerned with how to create one and how it works. So let’s just jump in and build one, and most of it will become abundantly clear through workflow.
Let’ start by going to the command line and running:
Chapter 6: Working with the RESTful Pattern 141 php artisan make:model Widget -m
We’re naming our model Widget, which is just a generic name that can represent anything. You can see that we added the -m flag, and that will simultaneously create a migration along with the model. This is excellent workflow efficiency.
After running the command, you should see confirmation of both files in the command line like so:
Since there is no models folder in Laravel, Widget.php will go directly into the app folder. You can find it next to your User model here:
Note: LIke I said, it’s not in the Providers folder, it’s in the app folder. Also, when you create a file by using artisan, git does not know about it and you have to tell git about it. That’s why the file is highlighted in red above. Use whatever method your IDE provides for adding it to your version control, if you are using version control, which is highly recommended.
Now let’s look at the new model file:
<?php
namespace App;
use Illuminate\Database\Eloquent\Model;
class Widget extends Model {
//
}
When I first saw this myself, I thought it was an empty stub, but it’s not. Much of the model logic is extracted out to the framework, so it makes working with it clean and easy. We will be adding to what you see here, but most of the heavy lifting is already done for us in the Active Record implementation.
Laravel has a name for its Active Record implementation. It’s called Eloquent and it gives us a highly intuitive syntax for doing common tasks with the DB. We will see that in action later.
For now let’s go to the other file we created, the migration. You can find that in database/migrations and will look like this:
Chapter 6: Working with the RESTful Pattern 143
You can see that artisan has done quite a lot of work for us. It named the table for us, widgets, which is plural of course. The convention is singular for model, plural for table name. It’s also giving us an auto-increment id column and a method that will create both created_at and updated_at datetime columns.
You can see it also gives us the down method to drop the table:
Schema::drop('widgets');
Now since the Widget model doesn’t serve any working purpose in the application, we are going to keep it extremely simple. All we are going to do is add a name column to the up method:
$table->string('name')->unique();
When you use the string method, the default is a varchar column with 255 characters, so once migrated the type on the column will look like:
varchar(255)
You can of course specify how many characters you want to allow as the second argument. That would look like this:
$table->string('name', 60)->unique();
So in that case it would limit it to 60 characters. But let’s stick with the default for now.
Also note, that we put a unique constraint on it. So now your up method should look like this:
public function up() {
Schema::create('widgets', function (Blueprint $table) {
$table->increments('id');
$table->string('name')->unique();
$table->timestamps();
});
}
I’m not going to provide a gist, since you only have to add the one line.
Now let’s run the migration from the command line:
php artisan migrate
And with that we have our widgets table. You can check it out in PhpMyAdmin:
Now let’s return to the Widget model.
Since we’re planning to add records to the widgets table, we need to add the following property to our Widget model:
Chapter 6: Working with the RESTful Pattern 145
/**
* The attributes that are mass assignable.
*
* @var array
*/
protected $fillable = ['name'];
This tells Eloquent that this is a mass assignable property, and if we didn’t have this, Laravel’s Eloquent wouldn’t allow us to save any records. Eloquent is the perfect name and you will understand why when we see it in action later.
Back to our fillable property. You’ll have to add to the fillable array every time you create a new column on a table that you want to save data to. Note that we don’t need to specify id, since it’s auto-increment, and we also don’t need to include the timestamps, they are also already included in the model.
So from a typical workflow standpoint, you could move onto to creating the routes, controller and views for our model. If you follow that pattern, you will make a model with migration, and then create the routes using a route resource. You could follow that by using artisan to make the controller, then work on the matching views and controller actions individually. I follow that workflow a lot.
Before we move on to demonstrating that, let’s look at a really cool feature that Laravel has for making test data.