Laravel views: знакомимся с Laravel blade и натягиваем шаблон

Автор: | 09.05.2017

Laravel-views-znakomimsya-s-laravel-blade-i-natyagivaem-shablonВсем привет!

Мы продолжаем создание сайта на Laravel 5. В предыдущих публикациях мы уже установили Laravel и настроили его запуск.

Сегодня наконец-то пришло долгожданное время писать код :-)

И я решил начать с фронтэнда, чтобы наш сайт уже начинал выглядеть презентабельно и его не стыдно было показать своим родственникам и друзьям :-)

Для этого нам понадобятся Laravel views и умение работы с шаблонизатором Laravel blade – собственной разработкой команды Laravel, а также знание его основных директив.

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

А для того, чтобы наш итоговый код был доступен широкой общественности, я решил создать для данного проекта публичный репозиторий на GitHub, ссылку на который вы сможете найти в конце статьи.

Возможно, в будущем, по вашим просьбам я создам серию уроков по разработке и других типов сайтов с более богатым функционалом (интернет-магазин, портал и т.д.), так что не забывайте писать об этом в комментариях и подписываться на обновления, чтобы быть в курсе новых публикаций.

Выбор шаблона для Laravel framework

В отличие от CMS, у которых графические шаблоны должны иметь определённую файловую структуру, в случае с фреймворками ситуация обстоит намного проще.

Шаблоны (templates) в их случае представляют собой набор HTML-документов и каталога (как правило, он носит название «assets») с различными JavaScript-библиотеками и картинками, которые используются в данном шаблоне.

Поэтому создать данный HTML-шаблон может без труда любой желающий и я хотел бы порекомендовать данное занятие всем, кто хочет себя попробовать в качестве фронтэнд-разработчика, т.к. чистые templates позволяют не вникать в структуру CMS.

И, кстати, благодаря таким особенностям структуры, уникальный дизайн для сайтов на Laravel и фреймворке в целом сделать намного проще, чем для CMS.

Однако, такая универсальность далеко не на руку нам, как разработчикам, которым предстоит данный шаблон «натянуть» или, другими словами, установить на сайт, базирующийся на фреймворке.

Дело в том, что универсальный HTML-шаблон не соответствует файловой структуре движка и прочих его особенностей (использование в framework шаблонизаторов, компоновщиков кода, минификаторов и прочих инструментов), поэтому файлы придётся адаптировать под структуру фреймворка вручную.

По поводу технических характеристик… Вот здесь я вас ничем не обрадую, потому что их попросту нет, в отличие от CMS, где нужно смотреть, чтобы шаблон подходил к определённой версии движка, использовал определённые технологии (VQmod/ocMod в случае OpenCart, например) и т.д.

При выборе шаблона Laravel, как и для других фреймворков главное требование к технологиям должно быть «Никаких технологий» :-)

Я имею ввиду, что в списке технических требований, необходимых для работы шаблона, не должно быть названия никаких движков (OpenCart, Magento и т.д.) и их версий. Как правило, шаблоны Laravel называются кратко и лаконично «HTML template» — наличие данной или похожей фразы в названии, пожалуй, и должно быть единственным условием выбора, остальные критерии будут чисто эстетическими «нравится/не нравится».

Ну, и лучше, конечно, выбирать для Laravel Bootstrap шаблоны (хотя, сегодня, наверное, уже все работают на базе данной технологии).

Кстати, поддержка последней официальной версии Twitter Bootstrap (альфа, бета версии не в счёт) идёт у Laravel из коробки, причём, уже в виде скомпонованных и минифицированных файлов (app.js и app.css).

Но всё же, при использовании готовых шаблонов, лучше пользоваться теми версиями библиотек, которые идут с ними в комплекте, а стандартные Laravel ресурсы в таком случае можно вообще удалить (лично я делаю так).

Ну, а по поводу стоимости, то шаблоны для фреймворков ничем не отличаются от CMS: бывают как платные, так и бесплатные.

Ресурсы для скачивания всё те же:

  1. templatemonster.com
  2. market.envato.com и ресурсы, входящие в данный конгломерат:
    • themeforest.net
    • codecanyon.net и др.
  3. bootstraptaste.com

Отечественных глобальных бирж подобного масштаба, к сожалению, не встречал.

Я лично пользовался TemplateMonster и ThemeForest, но порекомендовать могу только первый из них (это видно из размещённой ссылки на ресурс) благодаря русскоязычному саппорту и удобным способам оплаты (включая WebMoney и Яндекс.Деньги).

На втором цены на шаблоны немного дешевле, но перечисленных преимуществ там нет. Кроме того, при оплате нас ждёт неприятный «сюрприз» в виде дополнительной комиссии при оплате с PayPal или MasterCard/VISA (других способов оплаты просто физически нет). При оплате с внутреннего счёта комиссия не взымается, но вы её всё равно заплатите при вводе денег на этот счёт :-)

В общем, как вы могли понять из всех вышеприведённой информации, уникальным шаблоном я решил не заморачиваться и взял готовый (и, естественно, бесплатный) c bootstraptaste.com с поэтическим названием Moderna, демо-версия которого доступна по адресу bootstraptaste.com/demo/Moderna.

Вы, конечно, можете взять любой другой, который вам нравится, принципы его установки на Laravel будут те же самые, что и в моём случае.

Устанавливаем шаблон на Laravel

Итак, займёмся «прикручиванием» шаблона.

Для этого распакуйте скачанный вами архив с файлами шаблона и скопируйте все его каталоги с ресурсами (кроме «contact») в каталог public, подтверждая перезапись файлов в существующих каталогах js и css (файлы при условии чистого движка не будут пересекаться).

Размещать ресурсы нужно в данном каталоге, т.к. он как раз предназначен для обращения к файлам внутри его по пути относительно корня сайта.

В моём примере сайт будет иметь url http://laravel.portfolio, следовательно, обращение к ресурсам будет происходить подобным образом: «http://laravel.portfolio/js/file.js».

Естественно, это при условии, что корень сайта был настроен в Laravel на директорию public.

Обращаться к файлам из данной директории мы будем с помощью функции-хэлпера Laravel asset(), которая формирует абсолютный url к ресурсу, переданному в качестве параметра.

Самое интересное, что данную функцию 1-в-1 повторяет хэлпер url(), отличаясь от неё только целевым предназначением, т.к. служит для формирования абсолютных url любого назначения, кроме ссылок на ресурсы.

Очень тонкая грань, согласен :-)

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

Если вы пользуетесь другим, добытым из других источников, то его файловая структура может отличаться от моей. В любом случае, ресурсами шаблона будет являться то, что имеет расширение, отличное от .html.

Сами шаблоны страниц (файл readme.txt копировать не нужно) переносим в директорию resources/views, предназначенную для представлений (view), которые в паттерне MVC служат для вывода информации, собранной в моделях и обработанной в контроллерах.

Для обращения к файлам из данной директории из кода мы будем использовать функцию-хелпер view(), что я продемонстрирую позже.

Главная страница сайта Laravel

Итак, начнём с лица сайта, его главной страницы.

Создавать мы её будем на базе документа index.html, входящего в комплект шаблона.

Первым делом, чтобы при открытии сайта мы видели содержимое данного документа, необходимо прибегнуть к Laravel роутингу и прописать соответствующее правило в файле routes/web.php.

Данный файл актуален для Laravel 5.3+ и содержит правила роутинга, т.е., описания действий, которые необходимо выполнять при переходе по соответствующему url необходимым методом (POST/GET и т.д.).

В предыдущих версиях Laravel данный файл можно найти по пути app/routes.php.

Итак, открываем требуемый файл и можно смело удалить всё его содержимое :-) По умолчанию он содержит один-единственный роут (правило) для главной страницы, отображающий содержимое view (представления) welcome.blade.php.

Данный файл нам больше не потребуется, т.к. он является заглушкой и не несёт никакой пользы от присутствия на сайте, поэтому его также можно удалить.

В итоге, файл роутов на данном этапе должен содержать одно-единственное правило для главной страницы (можете как отредактировать существующее, так и удалить всё содержимое и вставить код ниже), которое будет выглядеть так:

Route::get('/', function () {
    return view('index');
});

Данный код будет возвращать содержимое Laravel view index при обращении к корневому url сайта.

Чтобы проверить работоспособность наших действий, вводим в браузере следующий url: http://laravel.portfolio/.

И что же мы видим?

oshibka-pri-laravel-blade-view-v-html-formate

Не очень-то похоже на главную страницу шаблона, правда? :-)

При использовании Laravel view есть один нюанс: собственный шаблонизатор Laravel blade.

Следовательно, Laravel views могут содержать различные директивы шаблонизатора (в случае с blade они начинаются с символа «@»). Но, чтобы они стали доступными, файлы представлений должны иметь расширение *.blade.php.

Следовательно, чтобы мы могли вывести содержимое Laravel view на экран с помощью хэлпера view(), нужно поменять расширение файла index с html на blade.php.

Если вы всё сделали правильно, то можно в браузере полюбоваться на главную страницу сайта, которая теперь будет выглядеть так:

primer-ustanovlennogo-laravel-shablona

Для остальных страниц Laravel шаблона можно поступить подобным образом, но давайте не будем спешить и усложнять себе жизнь.

Laravel blade содержит массу директив, которые призваны облегчить работу разработчикам. Одной из них является @extends, позволяющая страницам следовать какому-то определённому шаблону, т.е. использовать повторяющиеся куски кода (layouts или макет), не прописывая их в каждом документе заново.

Для того, чтобы найти такие повторяющиеся фрагменты, нам для начала нужно внимательно изучить структуру страниц шаблона.

При детальном анализе внешней структуры практически любого современного многостраничного сайта можно выделить одинаковые элементы (хедер, футер, сайдбар и т.д.).

В нашем шаблоне на всех страницах сайта есть одинаковые блоки вверху страницы (логотип и меню) и внизу (ссылки на социальные сети, копирайты и т.д.) – хэдер и футер.

Единственное, что на страницах различается – это зона контента, которая расположена между указанными блоками.

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

Для таких файлов создадим отдельный каталог в папке resources/views нашего проекта под названием «layouts».

Для формирования главного макета, содержащего условную схему страницы, создадим файл _layout.blade.php, в который перенесём код из index.blade.php.

В файле главной странице всё удаляем и вместо этого прописываем следующее:

@extends('layouts._layout')

Директивы шаблонизатора – это не функции PHP, поэтому не нужно ставить после них «;» или другие символы, иначе они будут присутствовать на скомпилированной странице в браузере.

В качестве параметров директива @extends принимает имя файла макета (без расширения blade.php), путь к которому нужно указывать относительно папки Laravel проекта resources/views.

При использовании @extends нам ещё понадобятся сопутствующие директивы @yield и @section, но о них мы поговорим немного позже.

Итак, из главного шаблона выносим повторяющиеся блоки в отдельные файлы.

В первую очередь, вынесем подключение стилей и скриптов.

Для файла стилей создаём макет styles.blade.php и выносим следующий код из тега <head>:

<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="author" content="http://bootstraptaste.com" />
<link href="css/bootstrap.min.css" rel="stylesheet" />
<link href="css/fancybox/jquery.fancybox.css" rel="stylesheet">
<link href="css/jcarousel.css" rel="stylesheet" />
<link href="css/flexslider.css" rel="stylesheet" />
<link href="css/style.css" rel="stylesheet" />
<link href="skins/default.css" rel="stylesheet" />

Из соображений SEO тэги <title> и <meta name=”description”> оставим в исходном шаблоне, чтобы для каждой страницы сайта значение этих элементов было уникальным.

Остальные meta-тэги не должны иметь уникальные значения на каждой странице, поэтому поместим их вместе со скриптами.

Также пропишем пути к файлам с помощью хэлпера asset(), о котором я уже упоминал ранее.

Вызов в шаблонах blade Laravel хэлперов, переменных и прочих конструкций производится с помощью следующей конструкции:

{{ $peremennaya }}

Следовательно, а нашем случае, подключение файлов через asset будет выглядеть так:

<link href="{{ asset('css/bootstrap.min.css') }} " rel="stylesheet" />

Переподключите подобным образом остальные css-файлы самостоятельно.

По умолчанию, Blade экранирует HTML код в выводимых подобным образом элементах. Поэтому, если вы выводите текст, содержащий HTML-тэги, то они будут показаны как текст. Чтобы отключить экранирование и увидеть разметку, нужно написать:

{!! $peremennaya !!}

Если нужно будет вывести фигурные скобки вместе с выводом переменной, пропишите следующее:

{{!! $peremennaya !!}}

Кстати, если вы захотите что-то закомментировать внутри кода Laravel blade-документа, то в данном шаблонизаторе для этого есть специальная директива {{— comment —}}. Данный формат комментариев использовать даже предпочтительнее языковых комментариев JS, CSS, HTML и т.д., т.к. blade-комментарии не отображаются в итоговом коде HTML-страницы в браузере, как первые.

Итак, стили мы вынесли. Нужно теперь подключить файл с ними в файле макета, для чего в _layout.blade.php удаляем код, вынесенный в файл styles.blade.php, и вместо него прописываем:

@include('layouts.styles')

Данная директива @include служит для подключения blade Laravel views внутри себе подобных :-) При этом все переменные, присутствующие в родительском view становятся доступными и в подключаемом.

В качестве параметров, как и у @extends, принимается имя файла представления, а также, могут быть переданы дополнительные переменные в формате:

@include('layouts.styles', ['var1' => $var1, 'var2' => 'var2'])

Если вы всё сделали правильно, то внешний вид главной страницы не должен будет поменяться – вёрстка не поламается и оформление сайта не испортится. Как говорится, отсутствие результата – тоже результат :-)

Теперь аналогичным образом вынесем из главного макета подключение js-скриптов. Подключаются они правильно, в самом конце документа, что позволяет увеличить скорость загрузки страниц и благотворно влияет на поисковое ранжирование Google и прочими поисковыми системами.

Поэтому местоположение менять не будем, изменим лишь способ подключения.

Создаём scripts.blade.php с кодом:

<script src="{{ asset('js/jquery.js') }}"></script>
<script src="{{ asset('js/jquery.easing.1.3.js') }}"></script>
<script src="{{ asset('js/bootstrap.min.js') }}"></script>
<script src="{{ asset('js/jquery.fancybox.pack.js') }}"></script>
<script src="{{ asset('js/jquery.fancybox-media.js') }}"></script>
<script src="{{ asset('js/google-code-prettify/prettify.js') }}"></script>
<script src="{{ asset('js/portfolio/jquery.quicksand.js') }}"></script>
<script src="{{ asset('js/portfolio/setting.js') }}"></script>
<script src="{{ asset('js/jquery.flexslider.js') }}"></script>
<script src="{{ asset('js/animate.js') }}"></script>
<script src="{{ asset('js/custom.js') }}"></script>

И подключаем наш макет в файле _layout.blade.php вместо приведённого выше кода с помощью следующей строки:

@include('layouts/scripts')

Проверить правильность действий вам поможет переключение слайдов на верхнем баннере, нажатие на кнопку «Вверх» внизу страницы и сообщения в консоли браузера.

Итак, скрипты и стили мы вынесли. На очереди ещё два больших, повторяющихся фрагмента – хэдер и футер.

Начнём с хэдера. Для этого создаём файл в той же директории — resources/views/layouts с названием header.blade.php и перенесём в него из главного шаблона тэг <header> со всем его внутренним содержимым.

В главном макете _layout.blade.php подключаем вырезанный кусок знакомым способом:

@include('layouts/header')

То же самое проделываем и с футером, вырезая элемент <footer> со всем содержимым из главного шаблона. Вместо вырезанного кода вставляем аналогичный предыдущим примерам код:

@include('layouts/footer')

На этом перенос повторяющихся фрагментов страниц в отдельные файлы завершён.

Оставшийся большой HTML-блок является контентом, который для каждой страницы будет уникальным. Для того, чтобы зарезервировать место для него в главном макете, воспользуемся следующей директивой шаблонизатора Laravel blade:

@yield(‘content’)

Разместим данную строку сразу после подключения файла хэдера в главном шаблоне _layout.blade.php, а весь html-код, который находится в <div id=»wrapper»> после прописанной нами только что директивы, вырезаем.

Затем идём в resources/views/index.blade.php и прописываем следующую конструкцию:

@section(‘content’)

@stop

Вставляем между данными директивами наш вырезанный код, сохраняемся и проверяем результат работы в браузере. Если вы всё сделали верно, то ничего не должно было измениться.

Давайте теперь разбираться, что же мы такое сделали :-)

В главном шаблоне _layouts.blade.php мы с помощью директивы @yield забронировали место для секции «content», содержимое которой мы должны будем прописывать в каждом файле страницы сайта внутри директивы @section с названием секции «content», которая закрывается директивой @stop.

В итоге, наш главный макет _layout.blade.php должен был принять следующий вид:

<!DOCTYPE html>
<html lang="en">
<head> 
    <title>Moderna - Bootstrap 3 flat corporate template</title>
    <meta name="description" content="" />
    
    @include('layouts.styles')

</head>
<body>
    
    <div id="wrapper">
        @include('layouts/header')

        @yield('content')

        @include('layouts/footer')
    </div>
    
    <a href="#" class="scrollup"><i class="fa fa-angle-up active"></i></a>
    @include('layouts/scripts')
    
</body>
</html>

Вроде бы всё симпатично получилось, однако, нет предела совершенству :-)

Лично мне не нравится один момент.

SEO-тэги <title> и <meta name=”description”> выносились в макет с благой целью – сделать их содержимое различным на разных страницах сайта, а сейчас они будет содержать постоянно один и тот же текст.

Чтобы разобраться с этой недоработкой, мы вместо статического текста организуем вывод с помощью переменных, значения которым будем задавать программно.

В итоге, шапка главного шаблона примет следующий вид:

<title>{{ $title }}</title>
<meta name="description" content="{{ $description }}" />

Эти переменные мы будем задавать в контроллерах соответствующих страниц при выводе информации на экран. Пока же, чтобы не оставлять их пустыми (да и избежать ошибок Laravel об использовании необъявленных переменных), зададим им значения в файле роутинга следующим образом:

Route::get('/', function () {
    return view('index')->with('description', 'Moderna - Главная страница')
                        ->with('title', 'Moderna - Главная страница');
});

Так будет выглядеть передача данных в шаблон Laravel при переходе на главную страницу сайта. Как видите, для передачи данных в Laravel используется метод with, который принимает в качестве аргументов имя передаваемой переменной и её значение. Для каждой переменной требуется отдельный вызов метода.

Если хотите передать все данные сразу в виде массива – нет ничего проще :-)

В Laravel данные в шаблон можно передавать и таким способом:

Route::get('/', function () {
    return view('index', ['description' => 'Moderna - Главная страница', 
                            'title' => 'Moderna - Главная страница']);
});

Также можно использовать ещё и такую вариацию последнего метода:

Route::get('/', function () {
    $data = array('description' => 'Moderna - Главная страница', 
                  'title' => 'Moderna - Главная страница');
    return view('index', $data);
});

Для других страниц пропишем следующее правило:

Route::get('/{page}', function ($page) {
    $data = array('description' => 'Moderna - ' . $page, 
                  'title' => 'Moderna - ' . $page);
    return view($page, $data);
});

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

В нашем примере переменная, содержащая имя страницы, просто будет передаваться в шаблон для формирования заголовка и описания страницы.

Ну, а как же проверить это правило, если у нас ещё нет ни одной страницы, кроме главной?

Страница портфолио Laravel проекта

Давайте, в качестве примера, разработаем Laravel blade документ для страницы «Portfolio». Для этого создаём в папке resources/views файл с названием portfolio.blade.php и копируем в него содержимое portfolio.html.

Удаляем повторяющийся код, который мы подключаем в главном макете _layout.blade.php, т.е. содержимое тэгов <head>, <header> и <footer>. Оставляем в файле шаблона только часть, расположенную между хэдером и футером, – область контента.

Оборачиваем её в используемые ранее тэги:

@section(‘content’)
   {{-- контент страницы --}}
@stop

И подключаем наш главный шаблон, прописав в самом начале файла, перед объявением секции контента, следующую конструкцию:

@extends(‘layouts/_layout’)

Итоговый код файла приводить не буду, т.к. он достаточно объёмный. Просто перейдите на страницу с портфолио в браузере, воспользовавшись элементами навигации сайта или введя прямой адрес http://laravel.portfolio/portfolio.

Если вы всё сделали верно, то вы увидите страницу с подключёнными стилями и валидной вёрсткой. Если же вместо этого вы увидели сообщение об ошибке – ознакомьтесь с её текстом, и если он не натолкнул вас на мысли – пишите его в комментариях под статьёй, чтобы я помог вам разобраться.

Laravel view с хлебными крошками

Повторный обзор кода страниц сайта помог мне выделить ещё один общий блок – это область под хэдером с «хлебными крошками».

Соответственно, также вынесем её в отдельный файл шаблона, который будем потом подключать.

Кстати, «хлебные крошки» в данном шаблоне организованы абсолютно неверно – на каждой странице прописаны вручную. В масштабах корпоративного сайта эта погрешность допустима, но на больших проектах такой способ будет крайне нерациональным.

Поэтому на данном этапе мы оставим всё, как есть, зарезервировав под список «крошек» секцию в макете, но в будущем сделаем формирование «хлебных крошек» автоматическим, о чём я напишу в отдельной статье.

А пока займёмся вынесением кода в отдельный шаблон. Для этого в resources/views/layouts создадим файл breadcrumbs.blade.php и перенесём  в него следующий блок кода из portfolio.blade.php:

<section id="inner-headline">
    <div class="container">
        <div class="row">
            <div class="col-lg-12">
                <ul class="breadcrumb">
                    <li><a href="#"><i class="fa fa-home"></i></a><i class="icon-angle-right"></i></li>
                    <li class="active">Portfolio</li>
                </ul>
            </div>
        </div>
    </div>
</section>

Содержимое тэга <ul class=»breadcrumb»> у нас будет различным на разных страницах, поэтому резервируем секцию с помощью кода:

@yield(‘breadcrumbs’)

Эту строку нужно вставить вместо списка «хлебных крошек»:

<ul class="breadcrumb">
   <li><a href="#"><i class="fa fa-home"></i></a><i class="icon-angle-right"></i></li>
   <li class="active">Portfolio</li>
</ul>

Список же со всем содержимым мы вырезаем и вставляем обратно в portfolio.blade.php, оформив код в виде секции breadcrumbs, которую мы вставляем после объявления секции content.

На данном этапе, в принципе, у нас нет острой необходимости делать «секцию в секции», можно было бы секцию breadcrumbs смело размещать перед content.

Но, заглядывая наперёд, когда «хлебные крошки» у нас будут формироваться программно и подключаться из единого файла, нынешний вариант удобнее, т.к. вместо кода секции мы просто вставим ссылку на требуемый файл, избежав перепрыгиваний по коду. Думаю, логика понятна.

В итоге, код страницы «Портфолио» будет иметь такой вид:

@extends('layouts._layout')
@section('content')
@section('breadcrumbs')
    <ul class="breadcrumb">
        <li><a href="#"><i class="fa fa-home"></i></a><i class="icon-angle-right"></i></li>
        <li class="active">Portfolio</li>
    </ul>
@stop
{{-- элементы контента --}}
@stop

Всё, что осталось, — это подключить шаблон «хлебных крошек» breadcrumbs.blade.php в нашем главном макете _layout.blade.php с помощью следующего кода, который необходимо вставить перед объявлением секции контента:

@include('layouts/breadcrumbs')

Теперь точно всё :-) Если вы всё сделали правильно – то на странице «Портфолио» ничего не должно было измениться.

Ах да, теперь у нас на главной странице появилась депрессивная чёрная полоса под хэдером, т.к. мы прописали подключение шаблона «хлебных крошек» в главном макете, на базе которого формируются все страницы.

Чтобы избавиться от этого маленького бага, сделаем подключение шаблона «хлебных крошек» для всех страниц, кроме главной, обернув строку подключения файла breadcrumbs.blade.php в _layout.blade.php следующим условием с помощью директивы @if:

@if(Request::path() != '/')
   @include('layouts/breadcrumbs')
@endif

Как видите, условие заключается в проверке части urlа текущей страницы, которая следует за названием сайта. Получить её нам помогает метод path() класса Request, к которому мы обращаемся и проверяем значение, которое он вернул.

После чего строка на главной странице исчезнет, а на остальных страницах блок хлебных крошек останется на своём месте.

Оформление остальных страниц Laravel шаблона

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

Всё, что вам потребуется – это создать файл с расширением .blade.php, назвав его так же, как и оригинальный файл шаблона, указать родительский макет с помощью @extends, описать секцию контента и вставить в ней всё, что находится между хэдером и футером в исходном файле.

Кстати, не забудьте после создания страниц поменять ссылки в главном меню сайта, которое расположено у нас в файле resources/views/layouts/header.blade.php, убрав из названий приставку «.html», а то страницы будут недоступны через элементы навигации, только по прямым ссылкам.

Также пройдитесь поиском по проекту в вашем редакторе кода и исправьте ссылки на главную страницу типа <a href=”index.html”>, прописав в качестве url «/».

Выполняя аналогичную финальную проверку файлов перед заливкой в репозиторий, я обнаружил ещё один небольшой баг шаблона. Не смотря на то, что страницы «Features» у нас нет – есть только пункт главного меню – в «хлебных крошках» есть соответствующий элемент на страницах «Components», “Typography” и “PricingBox”.

Это не правильно ни с точки SEO, ни с точки здравой логики, которая подсказывает, что элементы в «хлебных крошках» должны содержать ссылки, которую в данной ситуации невозможно поставить на несуществующую страницу.

Поэтому на всех вышеупомянутых страницах в секции breadcrumbs удалите элемент с текстом «Features» — он там ни к чему.

И ещё не будет лишним прописать по ходу редактирования пути к картинкам через хэлпер asset, которым мы пользовались в начале урока для подключения файлов стилей.

Также не забудьте удалить исходные файлы шаблона с расширением .html – они нам больше не понадобятся.

После правильно проделанной работы страницы сайта должны загружаться без ошибок и ни один элемент не должен пропасть – для образца используйте демо-версию шаблона Moderna, ссылку на которую я приводил в начале статьи.

А код страниц вы можете посмотреть в репозитории данного проекта на GitHub, которые оформлены в виде первого коммита.

Вы, конечно, можете просто скопировать их к себе в проект, но не рекомендую это делать, т.к. написание кода своими руками будет в 100 раз полезнее, в первую очередь, для вас самих.

Поэтому используйте мои образцы только для проверки и в случае возникновения каких-то ошибок и спорных моментов.

Если вы будете копировать мой GitHub репозиторий к себе на компьютер через Git целиком, то не забудьте после этой процедуры перейти в консоли в папку проекта и запустить следующую команду:


composer update --no-scripts

Это необходимо для установки файлов фреймворка (в частности, директории vendor, которой нет в Laravel репозиториях), причём тех их версий, которые прописаны в вашем файле composer.json. Этот момент, кстати, очень важен, т.к. при нестыковке версий движка и их зависимостей сайт работать будет некорректно.

На этом сегодня я с вами прощаюсь, успехов вам в выполнении задания. Если по ходу изложения сегодняшнего материала у вас возникли какие-то трудности и вопросы – не стесняйтесь делиться ими  в комментариях под статьёй. Буду рад любому вашему мнению.

Следите за обновлениями. Будет интересно :-)

  1. 5
  2. 4
  3. 3
  4. 2
  5. 1
6 голосов, в среднем: 5 из 5

8 комментариев к статье "Laravel views: знакомимся с Laravel blade и натягиваем шаблон"

  1. Владислав

    Великолепно всё расписано, многое что не понял сперва, после прочтения данной статьи встало на свои места. Спасибо!

  2. Edred

    Очень ясно и доходчиво! Прекрасный урок!

    Но вот в мелочах есть замечания, вы не очень аккуратны.

    Во-первых, инклюды вы пишете где через точку, где через слэш, никак не объясняя почему такое разное употребление. Например:

    @include('layouts.styles')
    @include('layouts/scripts')
    

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

    Во-вторых, вы в примерах конструкций используете разные кавычки, это несколько путает вначале, если же просто копировать ваш код к себе — то будут ошибки. Например, у вас в примерах использования инструкции @yield употребляются такие кавычки. Наверное, когда вы копировали из вашей IDE такие кавычки вылезли, не знаю. Я пробовал примеры в Notepad++, если в него от вас инструкции копировать — потом Laravel выдаст ошибку.

    1. Pashaster Автор

      Здравствуйте! Спасибо за комментарий.

      По поводу использования точек в Laravel вместо слэшей при указании путей к файлам — данная привычка у меня выработалась после того, как я пытался развернуть свой Laravel проект, разрабатываемый под Windows, на сервере с Ubuntu. Как итог — сайт не работал, постоянно вываливались ошибки о том, что невозможно найти какой-то view.

      С тех пор я и стал указывать пути через точку (благо, что в Laravel возможно использовать такой вариант), т.к. данный метод является кроссплатформенным и работает независимо от ОС сервера.

      Кстати, если Вы вдруг не в курсе, в самом PHP по этой же причине не рекомендуется использовать слэши для указания путей к каким-либо файлам. Вместо этого нужно использовать предопределённую константу DIRECTORY_SEPARATOR.

      1. Edred

        Спасбо за разъяснение о точке и слэше, теперь все понятно. Буду везде использовать точку. Про DIRECTORY_SEPARATOR я знаю, правда, периодически ленюсь ее использовать (я написал уже пару сайтов на чистом php, теперь вот хочу фреймворк научиться использовать, надоело изобретать то, что уже кем-то раньше придумано гораздо лучше меня, типа кэширования и пр.).

        Не могли бы вы поподробнее объяснить разницу в использовании хелперов asset и url? В этом уроке вы используете asset, я прошелся по коду сайта-примера и везде все пути (и в href, и в img) прописал через него, и сайт работает — а затем, в следующем уроке вы мельком упоминаете необходимость использовать хелпер url. Не знаю, может дальше в уроках вы где-то об этом расскажете, я не люблю забегать вперед, если нет — то, пожалуйста, расскажите сейчас.

        1. Pashaster Автор

          По-моему я уже где-то писал по поводу разницы asset и url. В своё время тоже задавался подобным вопросом, пока не попал на обсуждение данного вопроса на Laracasts. В итоге народ пришёл к выводу, что разница хэлперов чисто функциональная.

          Т.е. url предназначен для формирования абсолютных url, а asset — для подключения различной статики, расположенной в папке public.

          Хотя, по сути, результат вызова url(‘test’) и asset(‘test’) будет одинаковым. Скорее всего, это было задумано для приложений с нестандартной структурой, у которых index.php расположен не в public. Тогда функции будут выдавать различные результаты. При использовании стандартной архитектуры Laravel изменений не заметно)

          Ну, и ещё, у функции url на один входной параметр больше, чем у asset:

          function url($path, $parameters = [], $secure = null){...}
          function asset($path, $secure = null){...}
          

          $parameters предназначен для дополнительных параметров, которые будут закодированы и добавлены к $path при формировании итогового URL. К примеру, следующий код:

          url('test', ['lang', 'en'], true)
          

          выдаст следующее:

          https://site.url/test/lang/en
          

          Сначала я думал, что данные из $parameters будут добавляться в виде GET-параметров к url, но когда протестил — честно говоря, не понял задумки разработчиков Laravel. Зачем делать для этого отдельный массив, если можно указать полный url в качестве параметра $path? Если кто понял — отпишитесь :-)

          Ну, и третий параметр в обоих хэлперах нужен для формирования url с учётом SSL — через https протокол.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *