Add an artisan make:view command

[svenluijten]

Adding a command like php artisan make:view would allow the user to generate view files via the command line instead of having to use their editor and/or filesystem.

Some options that may be interesting:

• php artisan make:view products.index -- Generates products/index.blade.php.
• php artisan make:view index --extends="_layouts.base" -- Extend an already existing view.
• php artisan make:view products.index --section="content" -- Scaffold out a section.
• php artisan make:view products --resource -- Generates an entire resource (products/index.blade.php, products/edit.blade.php, products/show.blade.php & products/create.blade.php).

These features would of course be limited to blade-only. If someone is using Twig (or another templating engine), they might appreciate an option like --extension to set the file extension:

• php artisan make:view products --extension="html.twig"

I already have an implementation of this here which can be used as inspiration.

[Garbee]

This would be a fantastic addition. For alternate formats though, I think it would be best to have a --type option that would take a string for the type to be used (defaulting to blade). The available options would be registered in a class which would handle grabbing the template files and setting up the data appropriately for that syntax. That would allow --extends and --section to be programmable for other syntaxes as well.

[wotta]

This is what I hoped to get implemented to.
But there should be at least some default code in.

Also it would be nice to automatically be able to pass data trough from the eloquent model.
Like so :
php artisan make:view website.content --extends="website._base" --section="content" --data="App\Users::all()" --appendData="content"

This would then scaffold out the following view :

@inject('data', 'App\User')
@extends("layouts.website.master")

@section("content")

    {{-- This name would be dynamic to the model name. --}}
    <h1>Users</h1>

    {{-- Here is the data we passed trough --}}
    <ul>

        {{-- Always keep the first letter from the variable. --}}
        @foreach ($data::all() as $d)

            {{-- Get the data you want here. --}}
            <li>{{ $d-> }}</li>
        @endforeach
    </ul>

@endsection

[svenluijten]

I'm not a fan of that @concept-core. It should be kept simple and clean without too much overhead. Your idea could be neat for a package or own seperate command on a per-app basis, but it wouldn't really fit in the main Laravel codebase in my opinion.

[wotta]

@svenluijten hmm I think your right in the way you say that.
But keep in mind they shot of this idea multiple times : laravel/framework#14517

[assaqqaf]

I like this one:

php artisan make:view products --resource

[kingRayhan]

What about this? I will write this command

php artisan make:view posts --resource

And generate a full set of necessary view files for a resource controller.
So it will generate these files

posts/index.blade.php
posts/create.blade.php
posts/store.blade.php
posts/show.blade.php
posts/edit.blade.php
posts/update.blade.php
posts/destroy.blade.php

[wotta]

@kingRayhan that might be overkill, most of the times from what I have seen at least the only thing you need are the following views.
Index, create, edit and show.

Note that the create and edit could include a format view which hold the main form for both edit and create.

[kingRayhan]

@concept-core
ha ha,
Maybe I was over excited 😸

BTW: I found a third party artisan command package exactly what was I looking for.
You can check this.
https://github.com/svenluijten/artisan-view

[MadMikeyB]

+1 for baking this into core.

[mikizdr]

Already made solution:
https://github.com/svenluijten/artisan-view

[svenluijten]

@mikizdr Yep! This was mentioned in my original issue (last sentence), and in @kingRayhan comment here. Thanks, though 🙂

[taylorotwell]

This command could balloon up with options pretty quick unless we intentionally limited the scope. I would personally limit it to a simple --extends switch... in a perfect world that would probably scan for @yields in that layout and automatically make sections for them in the newly generated view but that could be tricky? What if the yield is a variable... or some concatenated string, etc.