Яндекс.Практикум

Сайт-визитка на Laravel. Часть 2

Итак, продолжу рассказывать как создать визитку на Laravel 4. Чтобы можно было следить за всеми этапами и поглядеть готовый результат, я создал проект на github по ссылке https://github.com/jean179/vizitka-laravel....
Сайт-визитка на Laravel

Итак, продолжу рассказывать как создать визитку на Laravel 4.

Чтобы можно было следить за всеми этапами и поглядеть готовый результат, я создал проект на github по ссылке https://github.com/jean179/vizitka-laravel. Кто не работал с git, рекомендую глянуть курс https://git-scm.com/book/ru/v1, а о начале работы с github есть не менее интересное руководство https://habrahabr.ru/post/125799/. По нему очень легко и удобно можно начать работать.

У github.com есть только один маленький недостаток — в нем нет возможности создать приватные репозитарии кода на бесплатном тарифе. Я лично платить 7$ в месяц «на поиграться» не готов. Зато есть альтернативный сервис для удаленной работе с git — это https://bitbucket.org/, где можно легко создавать точно такие же репозитории проектов, а на бесплатном тарифе есть возможность создавать 5 приватных репозитория. Но если проект не представляет особой коммерческой стоимости и может быть выложен в public, то github.com удобнее.

Этап 3. Роутинг приложений

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

Преступим к созданию контрольных точек приложения или роутингу.

Самый простой вариант — это использования анонимных функций-замыканий с простейшим перечислением роутов как они сделаны в шаблоне. Примерно так в файле app/routes.php:

Route::get('/', function() {
    return 'Главная страница';
});
Route::get('/about.html', function() {
    return 'О фирме';
});
Route::get('/blog.html', function() {
    return 'Новости фирмы';
});
Route::get('/services.html', function() {
    return 'Наши услуги';
});
Route::get('/contact.html', function() {
    return 'Контакты';
});

Если подставить в пустую установку, то будет срабатывать роуты. Можете попробовать набрать URL в строке браузера и в самом браузере будет менять текст в зависимости от URL.

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

Поэтому я предлагаю переписать все роуты кроме главного в один. Тем более, что по большому счету меняется только slug (или aliase — кто больше привык к такому термину) страницы.

Route::get('/', function() {
    return 'Главная страница';
});
Route::get('/{slug}.html', function($slug) {
    return 'Страница' . $slug;
});

Я просто сказал Laravel, что если после корневого слеша идет какой-то текст с расширением html, то сработает анонимная функция, куда передадутся в качестве параметра в переменную $slug. А функция просто выведет слова «Страница» и адрес страницы. В последствии нам эта переменная потребуется для выборки из базы страниц по slug для отображения.

Но теперь встала другая проблема — можно ввести любой бред после слеша и дать ему окончание .html и такой адрес будет валидный. Что тоже нас не слишком устраивает.

В Laravel есть возможность задать через регулярные выражение устраивающие нас значения slug. Вот и воспользуемся ими.

Среди программистов есть шутка, что ты мега-крут, если можешь прочитать регулярные выражения другого программиста :). Но тут мы не будет изобретать огромный велосипед, а просто сделаем перечисление нужных нам slug страниц:

Route::get('/{slug}.html', function ($slug){
    return $slug;
})->where('slug', '(about|blog|contact|services)');

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

Да, окончательная полировка роутов будет на последнем этапе перед выкаткой в «продакшен» со страницами 404 и так далее.

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

Этап 4. Шаблонизация в Laravel

По умолчанию в Laravel встроен шаблонизатор Blade, который выполняет очень важную функцию — отделения представления страницы от данных. Учитывая, что он довольно гибкий, Blade позволяет элегантно обойти некоторые трудные моменты в создании сайта, которые есть в других фреймворках типа HMVC. Идеология и синтаксис этого шаблонизатора чем-то похожа на шаблонизатор Twig и на шаблонизатор Django.

Шаблонизатор работает в файлах с расширением «имя-файла.blade.php»

Основные теги и подробности лучше прочитать в документации https://laravel.su/docs/4.2/templates .

Увы, подсветку кода сделаны только в редакторе SublimeText и в IDE JetBrains PhpStorm, Codelobster. Поэтому для работы с кодом я использую триал SublimeText 3.

Принципы шаблонов в Laravel

Laravel использует стандартную практику: берется основная разметка страницы и объявляется главным шаблоном. Шаблоном может быть сколько угодно и они ни к чему не привязаны.

Из него нарезаются кусочки и выносятся в отдельные файлы. Основной критерий здесь удобство. Чтобы не читать постоянно «портянку» с теми же многоуровневыми меню, боковой панелью и так далее, их выносят в отдельные файлы и подключают директивой @include('имя-файла').

Имя файла может иметь расширение blade, тогда там будет работать шаблонизатор. А может не иметь. Когда подключается файл через @include, не нужно указывать расширение «.blade.php». А если вы создаете такие файлы в папках, то доступ к ним идет так: 'имя-директории.имя-файла'. Вложенность идет от корневой папки с вьюхами app/views.

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

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

Хелперы

Шаблонизатор Blade имеет замечательные возможности. Но формировать элементы html руками можно, но не удобно и не гибко. Допустим, вы руками сделали меню и все работает. Но вот вы нашли ошибку в slug и исправили её. Теперь придется исправить и в куче шаблонов, где есть ссылка на эту страницу. Когда проект маленький типа визитки, это еще можно сделать. Но когда будет большой и сложный проект, да еще вам придется вернуться к нему через год, когда вы давно забыли что и как делали, это будет для вас сущее наказание.

Поэтому нужно стараться максимально использовать возможности самого Laravel для генерациии чего-либо.

Вот ссылки на генераторы html и некоторые полезные хелперы: https://laravel.su/docs/4.2/html , https://laravel.su/docs/4.2/helpers . Самые ходовые на этом этапе хелперы генерации URL и вот их-то и нужно обязательно разобрать и применять где можно. Впрочем, генерация форм потребуется несколько позже, пока сосредоточимся на генераторах URL.


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

Понравилась статья? Поделиться с друзьями:
IPCalc Blog
Комментарии: 4
  1. Юрий

    Спасибо за труды, не хотите ли перевести свои уроки на laravel 5? Хотя может для того чтобы разобраться в чем то достаточно и 4.2

    1. admin (автор)

      Если честно, 5 меня не вставила — тяжелее, навороченее. Ушло на мой взгляд из 5 что-то, что так притягивает меня в Laravel. Так что извините.

  2. Солдат

    Делайте ссылки в конце статей на след часть и след части делайте на предыдущие, как на хабре, пожалуйста, это удобно.

    1. admin (автор)

      Спасибо за совет, сделаю сегодня обязательно. Я как-то рассчитывал на плагин. Но, думаю, сделать в конце список со всеми частями статьи будет не лишним.

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

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: