Laravel 4 Контроллер Templating/Blade - Правильный метод?

Я читал документацию Laravel 4 и делаю демо-приложение, чтобы помочь с обучением.

Я не мог найти много документации по шаблонам просмотров с помощью blade-серверов и контроллеров. Каков правильный метод или он подходит к личным предпочтениям?

например. 1

<сильные > Контроллеры /HomeController.php

protected $layout = 'layouts.main';

public function showWelcome()
{
    $this->layout->title = "Page Title";
    $this->layout->content = View::make('welcome');
}

Просмотров/макеты/main.blade.php

<html>
<head>
    <title>{{ $title }}</title>
</head>
<body>
    {{ $content }}
</body>
</html>

Views/welcome.blade.php

<p>Welcome.</p>

например. 2

<сильные > Контроллеры /HomeController.php

protected $layout = 'layouts.main';

public function showWelcome()
{
    $this->layout->content = View::make('welcome');
}

Просмотров/макеты/main.blade.php

<html>
<head>
    <title>@yield('title')</title>
</head>
<body>
    @yield('content')
</body>
</html>

Views/welcome.blade.php

@section('title', 'Welcome')
@section('content')
// content
@stop

Какое лучшее соглашение и/или преимущества вышеуказанного?

Ответ 1

Я не сохраняю информацию о макете в контроллере, я храню ее в представлении через

@extends('layouts.master')

Когда мне нужно вернуть представление в контроллер, я использую:

return \View::make('examples.foo')->with('foo', $bar);

Я предпочитаю этот подход, поскольку представление определяет, какой макет использовать, а не контроллер, который подвержен повторной факторизации.

Ответ 2

Мне не нравится ни один из них. Макеты, вероятно, самая странная часть Laravel. Версия контроллера на самом деле не имеет смысла; все методы контроллера требуют этого представления. Версия @yield - это беспорядок шаблона. Я составил этот "метод конкретных макетов":

public function index()
{
    return View::make('layouts.main', [
        'layout_data' => 'sup'
    ])->nest('content', 'welcome', [
        'view_data' => 'sup'
    ]);
}

Я думаю, что в документах следует упомянуть, что это вариант.

Ответ 3

Я предпочитаю второй, потому что он показывает более четкое разделение между вашим представлением и кодом контроллера. Мне кажется более логичным, что заголовок будет свойством представления контента, а не сочетанием вашего приветственного представления с вашим приветственным названием каждый раз.

В конце оба правильны и будут работать, но вторая альтернатива более удобна в обслуживании.

Ответ 4

Я предпочитаю первый метод, так как некоторые сайты имеют динамически сгенерированный заголовок из базы данных. Легко передать заголовок при использовании первого метода.