I remember I blogged about Laravel back in 2016 (time flies!), and reading them again, I am surprised that what I thought back in 2016 still applies today.

Today I am going to talk about some black magic I’ve encountered writing a test blog project. The bit that filling out the blog form and validating the data. Normally, when a form is posted to an URL, the controller validates the form data and throws validation exceptions if form is not validated, then the controller can redirect the browser back to the form along some error data to be displayed on the form. In Laravel, the redirecting back to the form is automatically done for you and somehow the view magically has the ‘errors’ variable in context.

I am seeing a lot of framework specific global functions but don’t know where they come from, such as “view()”, “redirect()” etc etc.

ORM

Again, as mentioned in part 1, since we are creating migration files first, then we won’t be able to define FK relationships directly point to another model. According to the “intermediate quickstart” tutorial, you have to be a bit lower level like:

$table->integer('user_id')->index();

Hang on… Would this create a FK constraint automatically like Django??

Still ORM

Let’s add a few things to this model. First, we will state that the name attribute on the model should be “mass-assignable”. This will allow us to fill the name attribute when using Eloquent’s createmethod:

class Task extends Model{
    protected $fillable = ['name'];
}

Hmm, what? Skimming through the tutorial, so this enables you to do this:

$request->user()->tasks()->create([
        'name' => $request->name,
    ]);

Still ORM – take 2

In Django, when you define a ForeignKey like this

class User(models.Model):
  email = models.EmailField()

class Task(models.Model):
  user = models.ForeignKey(User, related_name="tasks")

You can access the relationship in both ways automatically:

task.user
user.task_set.all()
user.tasks.all() // using optional defined related_name

But in Laravel, it seems you have to define the relationship in each model.

class User extends Authenticatable
{
    // Other Eloquent Properties...

    /**
     * Get all of the tasks for the user.
     */
    public function tasks()
    {
        return $this->hasMany(Task::class);
    }
}

class Task extends Model
{
    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = ['name'];

    /**
     * Get the user that owns the task.
     */
    public function user()
    {
        return $this->belongsTo(User::class);
    }
}

After setting up the quickstart project, I feel the project structure is quite different to Django. In Django a lot of code are organised in “app” domain, but it seems to me that multi-app is not something out-of-the-box in Laravel: https://laracasts.com/discuss/channels/general-discussion/laravel-5-multi-app-or-modular-applications

Instead, it seems the apps in Django is more similar to the “Service Providers” in Laravel.

ORM

While working on the quickstart project in Laravel, it seems to me that Eloquent doesn’t generate initial migratios based on model definition.

In Django, you define the model, then by running “makemigration” CLI command, it will generate initial migration files to create the database table for that model.

According to the quickstart project, it seems to be things work the other way around, you will have to manually create the migration files by running

php artisan make:migration create_tasks_table --create=tasks

And then create the model class by running

php artisan make:model Task