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

С пакетами всё просто: можно написать свой или использовать чужой. Готовых пакетов для алертов много. Мне за последнее время попалась пара: vinkla/alert и laracasts/flash. Я начну свои эксперименты со второго пакета. Если не пойдёт или что-то не понравится, попробую первый. Если и с первым ничего не выйдет, то напишу свой. А скорее всего, я всё перепробую и напишу свой, но начну таки с laracasts/flash. И начало это, как принято в Laravel, состоит из команды

composer require laracasts/flash

которая пакет установит. После установки, по традиции, редактирую файл config/app.php и делаю две вставки

'providers' => [
     ...
    Laracasts\Flash\FlashServiceProvider::class,
];
'aliases' => [
    ...
    'Flash' => Laracasts\Flash\Flash::class,
];

Практически всё. Теперь в шаблонах blade необходимо в нужном месте вставить одну строчку.

@include('flash::message')

Всё, можно применять. Для этого можно использовать фасад, алиас которого я прописал в файле конфигурации, либо функцию-хэлпер:

     // Хотим сообщить об ошибке с помощью фасада
     Flash::error('Что-то пошло не так!');
    // Используем хэлпер для сообщение об успехе
     flash()->success('Всё отлично получилось.');

Доступно 5 видов сообщений:

• Flash::info(‘Сообщение для вывода информации’)
• Flash::success(‘Сообщение об успешном производстве действия’)
• Flash::error(‘Сообщение об ошибке’)
• Flash::warning(‘Предупреждение’)
• Flash::overlay(‘Сообщение для вывода в модальном окне’, ‘Заголовок окна’)

Текст сообщения и его тип в виде значений ключей flash_notification.message и flash_notification.level сохранятся в сессии и будут извлечены при создании страницы. Если вставка в шаблоне для этого пакета есть, то всё должно произойти само собой. Ручная обработка сообщений, что может потребоваться при использовании не Bootstrap, а чего-нибудь другого, производится довольно просто:

@if (Session::has('flash_notification.message'))
    

        ×
         {{ Session::get('flash_notification.message') }}
    
@endif

Что на русский можно перевести как “Если есть сообщение в сессии, то будем его транслировать в соответствии с заданным уровнем тревожности”. Скобочки и буковки в этом коде расставить по вкусу в соответствии с используемыми инструментами. И лучше сохранить код в виде всё того же blade шаблона и вставлять его куда надо.

Если для алертов используются модальные окна, то нужно после подключения библиотек jQuery.js и Bootstrap.js добавить такой скрипт:

Вот кажется и всё.

У прекрасной тулзы “artisan” есть опция показа всех маршрутов роутера. Отличная штука. Я уже писал, что у меня в роутере всё очень скромно, ничего лишнего. И писал, что после выполнения

./artisan make:auth

происходит несколько трансформаций, после которых меняется и роутер.

<?php
Route::group(['middleware' => ['web']], function () {
	Route::get('/{id?}', 'PagesController@show')->where('id', '\d+');
	Route::get('contacts', 'ContactsController@getContacts');
	Route::post('contacts', 'ContactsController@postContacts');
});
Route::group(['middleware' => 'web'], function () {
    Route::auth();
    Route::get('/home', 'HomeController@index');
});

А теперь о магии: на рисунке ниже отчётливо видно две таблицы. Первая – это маршруты до изменения роутера, а вторая, соответственно – после. Состав не так важен. Важен размер.

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

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

 
// Authentication Routes...
$this->get('login', 'Auth\AuthController@showLoginForm');
$this->post('login', 'Auth\AuthController@login');
$this->get('logout', 'Auth\AuthController@logout');
// Registration Routes...
$this->get('register', 'Auth\AuthController@showRegistrationForm');
$this->post('register', 'Auth\AuthController@register');
// Password Reset Routes...
$this->get('password/reset/{token?}', 'Auth\PasswordController@showResetForm');
$this->post('password/email', 'Auth\PasswordController@sendResetLinkEmail');
$this->post('password/reset', 'Auth\PasswordController@reset');

Приятно, что маршруты не уводят в даль светлую, а заканчиваются готовыми для ввода данных шаблонами, со встроенными сообщения ошибок ввода. Реализация похожа на ту, что я показывал в публикации по отправке email. Точнее, у меня она сделана так же.

Регистрация пользователя

Аутентификации пользователя

Сброс пароля

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

./artisan migrate

О миграциях и операциях с ними я уже писал. Для начала работы с аутентификацией доработок не требуется и формы как раз рассчитаны на стандартные таблицы.

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

А быстрый тюнинг стандартной аутентификации я бы делал так:

1. Установить чистый Laravel
2. Установить скелет аутентификации ./artisan make:auth
3. Настроить подключение к базе данных
4. Накатить миграции ./artisan migrate
5. Зайти по адресу http://yuoir.site/register и создать минимум одного пользователя

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

Route::group(['prefix' => 'myauth', 'middleware' => ['web'], 'namespace' => 'Auth'], function() {
    Route::get('login', 'AuthController@showLoginForm');
    Route::post('login', 'AuthController@login');
    Route::get('logout', 'AuthController@logout');
});
Route::group(['prefix' => 'figwamadminka', 'middleware' => ['web','auth'], 'namespace' => 'Admin'], function() {
    Route::get('/', 'AdminController@getDashboard');
});

В первой строке сразу два интересных момента:

• ‘prefix’ => ‘myauth’ – маршруты начинающиеся с myauth
• ‘namespace’ => ‘Admin’ – по умолчанию используют контроллеры из директории app/Http/Controllers/Auth

Шестая строка добавляет интереса

• ‘middleware’ => [‘auth’] – доступ только через аутентификацию

И теперь для прохождения процесса аутентификации я должен идти по адресу http://mysite/myauth/login. Так же будет работать адрес /myauth/logout и всё. Регистрацию и сброс пароля я не заказывал. Нужно не забыть внести соответствующие правки в код blade шаблона. Разумеется префикс можно брать любой. Перед тестированием, чтобы не испытать чувство глубокого разочарование, нужно внести изменения в файлы app/Http/Controllers/Auth/AuthController.php, и app/Http/Middleware/Authenticate.php. В противном случае не будет находиться форма ввода логина/пароля при попытке неавторизованного доступа в закрытые обаласти, а после успешной аутентификации будет производиться переадресация в корень сайта.

<?php namespace App\Http\Middleware;
use Closure;
use Illuminate\Support\Facades\Auth;
class Authenticate
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @param  string|null  $guard
     * @return mixed
     */
    public function handle($request, Closure $next, $guard = null)
    {
        if (Auth::guard($guard)->guest()) {
            if ($request->ajax() || $request->wantsJson()) {
                return response('Unauthorized.', 401);
            } else {
                return redirect()->guest('myauth/login');
            }
        }
        return $next($request);
    }
}

и фрагмент AuthController.php

    /**
     * Where to redirect users after login / registration.
     *
     * @var string
     */
    protected $redirectTo = '/figwamadminka/dashboard';

Теперь при попытке входа по адресу /figwamadminka/dashboard и при прямом вызове /myauth/login будет вызываться форма аутентификации. После ввода логина и пароля пользователь перенаправляется на /figwamadminka/dashboard, где его “должна ждать” заранее подготовленная главная страница админки. На время отладки можно задействовать полученный вместе с каркасом аутентификации HomeController, из которого следует удалить конструктор, т.к. он повторяет действия, “заказанные” в роутере. Всё. Пилите админку, малята.

Я уже писал, что практически сразу после установки Laravel версии 5.2 рекомендую установить каркас авторизации, для чего нужно выполнить команду

./artisan make:auth

В результате обновится router.php, добавится несколько blade шаблонов и добавится HomeController, демонстрирующий как бы авторизацию. Если честно, то все эти действия и даже “более лучшие” можно совершить самостоятельно, но для начала сойдёт. Особенно в качестве демонстрации имеющихся в Laravel механизмов авторизации и аутентификации. Однако, как я писал ранее, на улице давно весна и простые вещи типа логин/пароль уже не удовлетворяют нас. Пришло время авторизации с помощью аккаунтов социальных сетей. И опять потребуется минимальное хотя бы планирование приложения.

Аутентификация пользователя – это, в терминах Laravel, определение свой-чужой: есть пользователь с введёнными данными в базе или нет. Есть – аутентификация прошла успешно. При этом данные для аутентификации одного и того же пользователя могут быть разные: логин/пароль, OAuth токен и что-нибудь ещё. Главное, чтобы пользователь мог доказать приложению, что это он. А есть ещё авторизация – это определение набора прав или операций, доступных конкретному пользователю. Пусть даже не аутентифицированному. И это не обязательно доступ в админку, но и комментарии, доступ к определённым информационным материалам и что там ещё разработчик придумал.

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

Оказывается мне нужна была служебная область, а я собирался реализовывать механизмы ограничения доступа. Неожиданно. В этом месте я остановлюсь для создания нового плана захвата Парижа. И да, я же писал: без плана – никуда.

Начнём с настройки. Laravel, если верить файлу конфигурации поддерживает доставку почты “smtp”, “mail”, “sendmail”, “mailgun”, “mandrill”, “ses”, “log”. В соответствии с выбором, который лучше произвести в файле .env, нужно указать и другие параметры, обеспечивающие работу email на конкретном сервере. Для хостинга одно, для домашнего сервера другое, а для выделенного или виртуального сервера и вовсе третье.

MAIL_DRIVER=smtp
MAIL_HOST=mailtrap.io
MAIL_PORT=2525
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null

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

Настроили? Проверяем. Для этого проще всего использовать tinker, известный ранее как Boris и являющийся REPL. Всё ясно? Тогда запускаем его и проверяем реальную работу доставки почты. Там ниже real@email – это реальный адрес, на который нужно доставить email. Желательно его указывать без ошибок.

[polygon@ihhi.dev]$ ./artisan tinker
Psy Shell v0.7.2 (PHP 5.5.25 — cli) by Justin Hileman
>>> Mail::send('email.test',
['data' => 'Test, test, test!'],
function($message) {$message->to('real@email')
->subject('Просто тест');
});
InvalidArgumentException with message 'View [email.test-blade] not found.'
>>>

Оп-с, неправильно записал имя blade шаблона. Хотел сделать test.blade.php в resources/views/email, но рука дрогнула. Запускаю с правильным именем шаблона.

>>> Mail::send('email.test-blade',
['data' => 'Test, test, test!'],
function($message) {$message->to('real@email')
->subject('Просто тест');
});
ErrorException with message 'PHP error:  Undefined variable: mydata in /www/dev/ihhindex/cv.ihhindex.dev/storage/framework/views/53c4829e48b94a5f7e7c823bc8903fc74064aa9f.php on line 8 (View: /www/dev/ihhindex/cv.ihhindex.dev/resources/views/email/test-blade.blade.php)'
>>>

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

>>> Mail::send('email.test-blade',
['data' => 'Test, test, test!'],
function($message) {$message->to('real@email')
->subject('Просто тест');
});
=> 1
>>> exit
Exit:  Goodbye.
[polygon@ihhi.dev]$

Всё получилось, почта ушла. И даже пришла. Сразу скажу, что команда, начиная с Mail:: и до }); может быть одной строкой. Здесь она отформатирована исключительно для удобства восприятия. Если будут найдены ошибки, то курсором придётся “гулять” по всей длине записи.

Теперь потребуется совершить три подвига:

• Добавить маршруты в router.php;
• Создать и заполнить кодом контроллер;
• Сделать вьюшки.

Да, чуть не забыл: перед стартом производства подвигов требуется план. Даже если подвигов всего три. И далее, в соответствии с планом, вычёркиваем сделанное.

Маршруты

Route::group(['middleware' => ['web']], function () {
	Route::get('/{id?}', 'PagesController@show')->where('id', '\d+');
	Route::get('contacts', 'ContactsController@getContacts');
	Route::post('contacts', 'ContactsController@postContacts');
});

Сейчас роутер у меня выглядит предельно просто: все запросы идут через middlware web и далее разруливаются. Вторая строка про вызов одностраничика и про то, что если в адресе обнаруживается число, то генерируется соответствующая версия страницы. Это фишка не для электропочты и на “боевом” сервере отключается.

А следующие две строки с маршрутом contacts про неё родимую. Метод get – вызвать функцию getContacts, которая отображает отдельно стоящую форму отправки. Это вспомогательная функция, т.к. я надеюсь, что вменяемый посетитель сразу правильно заполнит форму и отправит её с одностраничника. Но в случае непосредственного перехода по адресу /contacts будет отображаться эта форма. Она же отображается и при ошибке ввода, так что лишней работы здесь почти нет. Но прямой ссылки на эту страницу я давать не планирую. Метод post вызывает функцию postContacts, которая должна выполнить всю работу. Обе функции в контроллере ContactsController. На этом с маршрутами можно закончить.

Контроллер

Для начала неплохо бы его сделать. И лучше пустым, чтобы не убирать лишнее.

 ./artisan make:controller ContactsController

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

<?php namespace App\Http\Controllers;
use Mail;
use Validator;
use Illuminate\Http\Request;
use App\Http\Requests;
class ContactsController extends Controller
{
    //
}

Я добавил в контроллер почту и валидатор. Теперь быстренько организую функции. Сначала отображение формы

	/**
	 * Show contact form
	 * 
	 * @return view
	 */
    public function getContacts(){
        return view('frontend.pages.contact');
    }

Теперь обработку

/**
 * Post data from contact form
 * 
 * @param Request $request 
 * @return view
 */
public function postContacts(Request $request){
	$data = $request->all();
    $messages = [
        'required'  => 'Это поле обязательно для заполнения.',
        'string'    => 'Введены недопустимые символы.',
        'min' 		=> 'Маловато знаков. Минимум - :min',
        'max' 		=> 'Многовато знаков. Максимум - :max',
        'email'     => 'Это  не похоже на адрес email',
        'url'      	=> 'Это  не похоже на адрес сайта',
    ];
	$validator = Validator::make($data, [
        'contactname' 	=> 'required|min:3|max:255',
        'email' 		=> 'email|required',
        'website' 		=> 'url',
        'message' 		=> 'required|min:10|max:255',
    ], $messages);
	if ($validator->fails()) {
        return redirect('contacts')
                    ->withErrors($validator)
                    ->withInput();
    }
    Mail::send('email.form', ['data' => $data], function($message) use ($data)
    {
     	$message->from($data['email'] , $data['contactname']);
    	$message->to('real@email', 'CV Form')->subject('CV mail form');
    });
    return view('frontend.pages.form-ok', ['name' => $data['contactname']]);
}

Надеюсь всё понятно:

• Строки 9-16 – я создал свои версии сообщений об ошибках ввода. Делать перевод в файлах локализации не хотелось по описанным выше причинам. И ещё один нюанс: использовать сообщение “Поле contactname обязательно для заполнения” мне не хочется, а стандартные сообщения показывают не названия, которые видит посетитель, а имена, используемые при генерации полей и они часто сильно отличаются.
• Строки 17-22 – правила проверки пользовательского ввода. Обращаю внимание на поле website – оно не обязательно для заполнения, но если уж посетитель решил в него что-нибудь написать, то потребуется сделать это правильно. И ввести http:// перед адресом, или создать правило самому.
• Строки 23-27 – в случае ошибки сообщаем об этом пользователю и используем вспомогательный шаблон, а не весь одностраничник. И передаём в него как сообщения об ошибках, так и данные, введённые пользователем. Многие не вводят повторно данные в форму, если они исчезли при ошибке.
• Строки 28-32 – формирование и отправка почты. Так же я передаю в шаблон form.blade.php весь массив данных из формы. С названием вьюхи я ошибся и оно выглядит провокационно, но пока менять не буду.
• Строка 33 – вызов страницы с сообщением об успешной отправке. Успех, кстати, не гарантирован, но проверки я не делаю. Потом нужно будет добавить. При формировании сообщения я использую имя автора, для чего передаю его в шаблон. Мне не трудно, а человеку приятно. Да, ещё, я вместо редиректа использую вью. Мне так больше нравится.

Шаблоны

И третья часть марлезонского балета: шаблоны blade. Вспомогательная почтовая форма. Она используется при прямом вызове или при наличии ошибок ввода. Ошибки можно выводить скопом в специально отведённом для этого месте, или под соответствующим полем ввода. Я выбрал второй вариант. При наличии ошибки поле ввода обводится красным бордюром и под ним выводится первое сообщение об ошибке. Одно.

@extends('frontend.layouts.default')
@section('content')


  

  
Контакты
    

      

        
Контактная форма
          

          

            
            

              
              {!! $errors->first('contactname', ':message') !!}
            
            

              
              {!! $errors->first('email', ':message') !!}
            
            

              
              {!! $errors->first('website', ':message') !!}
            
            

              {{ old('message') }}
              {!! $errors->first('message', ':message') !!}
            
            Отправить
          
        
      
      

        
Карта. Во-первых - это красиво.
        

        

          

        
      
    
  
 

@endsection

И в случае успеха выводится сообщение с помощью вот такого шаблона.

@extends('frontend.layouts.default')
@section('content')


  

  
Контакты
    

      

        
Контактная форма обработана
          

            
{{$name}}, всё отлично, письмо отправлено. Теперь попробуйте послать мне бандероль или денежный перевод. 
            
Перейти на единственную страницу сайта
            
прыг
        
      
      

        
Карта. Во-первых - это красиво.
        

        

          

        
      
    
  
 

@endsection

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

<!DOCTYPE HTML>
<html lang="en-US">
<head>
	<meta charset="UTF-8">
	<title></title>
</head>
<body>
	
Hello,
	
Name: {{ $data['contactname'] }}
	
E-mail: {{ $data['email'] }}
	@if ($data['website'])
	
Site: {{ $data['website'] }}
	@endif
	
Text: {{ $data['message'] }}
	
	
---

	Best regards,

	CV Team
</body>
</html>

Вот теперь всё. Кажется. На самом деле я уже готов всё переделать, но всплыла более насущная проблема: полное отсутствие присутствия админки. Я как-то забыл про неё, а заглянул в роутер и оба-на, нету. Не то, чтобы я хотел активно что-то редактировать на одностраничнике. Но лендинг должен собирать статистику. Можно подключить GA, LI или ещё что-нибудь. Можно добавить их просмотр в админку. Можно сделать свой сбор данных и их анализировать или смотреть “сырыми”. Это детали. И для их реализации админка нужна 100 пудов.

Ввиду безграничности интернета в части глупых шуток, размещать личный телефон на сайте не очень хочется. А вот форму обратной связи сделать нужно. И, кажется, таких форм может потребоваться несколько. Самое очевидное – это размещаемая в самом низу страницы контактная форма. Типа “напишите мне что-нибудь” и “ах, введённый вами email не соответствуют rfc” через “докажите, что вы не робот”. Вот сам видел: лендинг с капчей. Карл, с капчей!

Ну ладно, форму внизу страницы размещать нужно. Вдруг лендинг настолько бестолковый, что человеку даже хочется купить, но он не получил ответа на какой-нибудь свой вопрос. Тогда он пишет сообщение в духе “а такое же, но с перламутровыми пуговицами есть?” и отправляет его куда-то туда. И… А что должно произойти после нажатия кнопки “Послать”? Как вообще должна работать форма на одностраничнике? Варианты

• Обычная форма
  • Страница обновляется, сообщение об отправке замещает форму
  • Страница обновляется, сообщение об отправке дополняет форму
  • Страница на время заменяется страницей с сообщением “ОК” с последующим возвратом;
  • Страница заменяется страницей с сообщением “ОК”;
• Поп-ап форма;
• Форма по типу SPA;
• “Приклеенный” ярлычок “свяжитесь с нами”, постоянно присутствующий в окне.

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

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

И последний вариант: перегрузка только области страницы с контактной формой. У этого варианта два негативных момента: это сложнее и нужно специально отрабатывать сценарий отправки при отключенном у клиента JS. То есть вариант прекрасен, но сложен. Два раза сложен. И ещё при нём, как и при первом варианте, нужно обеспечивать возможность контакта не только в конце страницы.

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

Пока я не решил, какой вариант для связи на одностраничнике лучше, буду реализовывать их по одному. Сначала самый простой вариант: форма внизу, после отправки посетитель попадает на служебную страницу с отчётом. На служебной странице помимо ссылки на главную можно размещать какую-нибудь дополнительную информацию. Потом сделаю поп-ап. А за это время решу на чём делать SPA. Там вариантом очень много.

Сетевое издание ТИА – что-то очень похожее на городской портал Твери. Новости, реклама, блоги, конкурсы и что-то ещё с указанием регистрации в “ Федеральной службе по надзору…” от 2014 года. Если копнуть глубже, то найдутся записи пятилетней давности. Значит на Ларавель они не сразу перешли. . На этом сайте я узнал, что в Твери депутаты чего-то не сделали, что Нюша – это не розовая свинья из мультфильма, а певица и композитор, и что в Твери есть цирк. Как я жил без этого?

Портал народной аналитики Balalaika24.ru. Балалайка. Карл, они назвали свой сайт Ба-ла-лай-ка. 24. Я даже не знаю в каких словах описать те слова, которые я знаю и имею сказать. Зачем они так? Они – это “платформа для народных новостей и аналитики”. Платформа. Фреймворк. А ещё они “место для встреч независимых блоггеров, журналистов и просто неравнодушных людей”, некоммерческая организация и зарегистрированы как СМИ. Они собирают по всему и-нету политически озабоченных графоманов и предлагают им писать статьи. Одно может оправдать этот сайт: если собранный ими УКЖ все буквы будет тратить на Балалайку и больше нигде не будет отсвечивать.

Новостной портал который… Опять новости. На этот раз сайт http://inetia.ru. Если верить интерфейсу, то у них новости на десятке языков, какая-то система их ранжирования и какие-то настройки отображения в духе Медиаметрикса. Даже есть ссылка “городские порталы”. Интересно, там тверской сайт есть? Нет, вру, совсем неинтересно. Объём проделанной работы впечатляет, но результат мне не нравится. Может это и прекрасный проект, но я не являюсь его ЦА. Хотя бы в качестве СМИ не зарегистрирован.

Ну и, наконец, нормальный сайт по продаже шин. Он даже называется Автошина74 – суровый челябинский Ларавель: шины, диски, шиномонтаж. Нормальные коммерсанты оказались в абсолютном меньшинстве. Интересно, о чём это говорит?

Думаю, что рубрику “а вот ещё я сайт нашёл” нет смысла делать постоянной. Поиск сайтов на Laravel был интересен в самом начале, когда было не совсем понятно кто и что на нём делает. Теперь, после приватизации Ларавеля СМИшными сайтами, я задумался о том, какие бы мне новости на нём организовать. И уже есть пара идей.

Да-да, я решил сделать одностраничник. Точнее – переделать чисто пхп-шный концепт, позволяющий из блоков набрать какое-то подобие одностраничного сайта или лендинга. Никаких затей, чисто require block.php и куча стилей со скриптами. И решил я этот сайт оформить как посадочную страницу по продаже разработчика. Типа продаётся программист со всеми вытекающими последствиями. Разумеется страница будет безо всяких мотивирующих приколов типа “заказавшему программиста сегодня скидка 25%”. Хотя…

Ладно, о способах продажи людей в другой раз. Сейчас об инструментах: Laravel, Gulp, Bootstrap и всём том, о чём я писал ранее. Сделать несколько blade шаблонов и собрать из них страницу не является целью данной лабораторной работы. Хочется выяснить размер экономии в байтах при использовании Gulp и Sass. Суммарный размер файлов Bootsrap, jQuery и используемых модулей в моём случае составлял почти 700 килобайт. За красоту приходится платить, но такая цена мне кажется избыточной. Буду резать.

Понимаю, что за один раз всё лишнее я не уберу. Работа эта требует внимания и усидчивости. Для первого раза я хочу убрать самые очевидные излишки жира. Мне тут подсказали, что в быту это называется “липосакция”. Ну пусть так и будет. Sass файл Bootstrap выглядит вот так:

/*!
 * Bootstrap v3.3.6 (http://getbootstrap.com)
 * Copyright 2011-2015 Twitter, Inc.
 * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
 */
// Core variables and mixins
@import "bootstrap/variables";
@import "bootstrap/mixins";
// Reset and dependencies
@import "bootstrap/normalize";
@import "bootstrap/print";
@import "bootstrap/glyphicons";
// Core CSS
@import "bootstrap/scaffolding";
@import "bootstrap/type";
@import "bootstrap/code";
@import "bootstrap/grid";
@import "bootstrap/tables";
@import "bootstrap/forms";
@import "bootstrap/buttons";
// Components
@import "bootstrap/component-animations";
@import "bootstrap/dropdowns";
@import "bootstrap/button-groups";
@import "bootstrap/input-groups";
@import "bootstrap/navs";
@import "bootstrap/navbar";
@import "bootstrap/breadcrumbs";
@import "bootstrap/pagination";
@import "bootstrap/pager";
@import "bootstrap/labels";
@import "bootstrap/badges";
@import "bootstrap/jumbotron";
@import "bootstrap/thumbnails";
@import "bootstrap/alerts";
@import "bootstrap/progress-bars";
@import "bootstrap/media";
@import "bootstrap/list-group";
@import "bootstrap/panels";
@import "bootstrap/responsive-embed";
@import "bootstrap/wells";
@import "bootstrap/close";
// Components w/ JavaScript
@import "bootstrap/modals";
@import "bootstrap/tooltip";
@import "bootstrap/popovers";
@import "bootstrap/carousel";
// Utility classes
@import "bootstrap/utilities";
@import "bootstrap/responsive-utilities";

Каждая вставка – это функциональность и вес. Простой чек-лист позволяет выявить неиспользуемые блоки и просто выключить их. То же самое можно сделать и с остальными Sass файлами. Animation.css, к примеру, с 50 кил сокращается до полутора. Такие вот расклады. В результате css ужимается до 100 килобайт. И я надеюсь, что есть ещё резервы, но уже первые результаты вдохновляют.

Подозреваю, что столь же впечатляющие достижения ждут меня при обрезании jQuery и… отложу это счастье на потом. Просто солью весь скрипт в один файл. Дело в том, что набор скриптов я буду менять и пока не хочу погружаться в это болото. Хватило того, что я полез смотреть, что думает про сайт “PageSpeed Insights”: от Google и зарылся с настройку сервера, ревизию модулей Апача и сравнение с результатами Я.Вебмастера и других инструментов. А ведь я совсем не планировал этого. Ну её, преждевременную оптимизацию. Эксперимент признан удачным и пока на этом остановлюсь.

Сначала о моделях. В Laravel это расширение базового класса Model используемой ORM Eloquent. ORM (англ. Object-Relational Mapping) – это объектно-реляционное отображение. По-русски это звучит столь же непотребно: реализация ООП шаблона Active Record по кличке Красноречивый решает. А если на практике, то всё просто отлично. Создаём модель

php artisan make:model Article

или модель с миграцией

php artisan make:model Article --migration

Про миграции надеюсь, всё понятно: сгенерируется отличный каркас миграции по имени 2016_03_23_030541_create_articles_table.php, в который следует добавить нужное и убрать лишнее для создания таблицы articles. А каркас модели для управления этой таблицей по имени Article выглядит вот так

<?php  namespace App;
 
use Illuminate\Database\Eloquent\Model;
 
class Article extends Model
{
    //
}

И… А всё, можно создавать объекты класса Article и пользоваться всеми возможностями ORM. Например, создать новую статью, задать заголовок и содержимое, записать статью в базу:

$article = new Article;
$article->title = 'Крутая статья';
$article->title = 'Улётный текст статьи';
$article->save();

Это уже работает. Кроме шуток. Первые тесты я проводил на простых сайтах, имеющих примитивные сценарии работы. Создал модели и даже не заглядывал в них. Просто получал из базы нужные данные и перекидывал их в представления. В моделях Laravel вообще куча вполне разумных умолчаний, позволяющих использовать их без долгих прелюдий, а вся мощь ORM Eloquent наследуется и доступна без дополнительных телодвижений. Имя таблицы базы данных, к примеру – это множественное число имени модели в нижнем регистре. Не устраивает? Можно задать своё.

Но если выходить за пределы тестовых заданий и лабораторных работ, то придётся немного поработать как руками, так и головой. Голова потребуется для понимания связей в базах данных вообще и в Eloquent в частности. А руками связи нужно будет закодировать и заставить работать. И тогда без проблем будут находиться теги, авторы и комментарии статей, а так же статьи авторов и категорий. Связи решают. Такой вывод.

Для начала работы с Twitter Bootstrap требуется совсем немного. Базовый шаблон выглядит просто и понятно

<!DOCTYPE html>
<html lang=“en”>
<head>
    
    
    
    

    




    
    
    
  
  
    
Hello, world!

    
    
    

</body>
</html>

Подключены свежие стили и скрипты, включая jQuery. Можно исполнять весь репертуар. Довольно убогий, если честно. Да, тема тоже подключена, но… Одним словом, дорабатывать и дорабатывать. И это без учёта “мобайл фёст” и интересов мобильных пользователей: “вес” минифицированных стилей и скриптов почти 300 килобайт. И вроде грузить их пользователю всего один раз, но это не факт и далеко не у всех топовые девайсы в карманах. И да, это ведь ещё без текстов, картинок и прочего контента, за которым пользователь зашёл. Ведь никто не думает, что он за скриптами и стилями здесь, правда? И ещё есть деталь: чем меньше количество подключаемых файлов при одинаковом их размере, тем лучше. В идеале этих файлов может быть два: в начале со стилями и в конце со скриптами. А можно и вообще в тело документа шить. Короче, с этим нужно что-то делать.

Самый простой способ – это зайти на страницу Customize and download и на ней “галочками и точечками” отсечь лишнее, выбрать нужное и результат скачать. Даже можно с цветами, бордюрами и размерами поиграться. Выглядит неплохо. Но это при условии, если уже ничего не нужно менять. А если то одно прибавится, то другое убавится, а то опять всё взад вертать? Не находишься, говорят про такое в народе. И вот для этого придуманы всякие умные штуки из списка на предыдущей странице.

Сейчас я перечислю действия для создания прокачанного центра разработки фронтенда на базе Laravel. Рекомендую перед исполнением подобного сольного номера определиться с набором установки и дочитать текст до конца. А то вдруг оно и не нужно совсем.

Во-первых, совсем не обязательно использовать тот же набор, что и я. Самое главное понять: в Laravel легко встраивается механизм сборки css/js файлов из различных полуфабрикатов. Я для себя выбрал Bootstrap и SASS. Этот выбор позволяет легко подключать и другие популярные штуки типа Font Awesome и им подобные. Но можно использовать LESS, CoffeeScript, Stylus и что там ещё существует. Кстати, это касается не только текста. Можно собирать картинки в спрайты и ещё какой-нибудь непотребщиной заниматься. Дело личного выбора.

Итак, определились и поехали.

1. Проверяем наличие установленной Node.js

node -v

Получили версию? Идём дальше. Нет? Устанавливаем. rpm, dpkg, yum, apt-get или иной подходящий менеджер пакетов в руки. И главное не забыть установить npm. Без него не получится. С установленным npm ставим глобально gulp и bower. Можно и в одну строку, если что. Я такие действия от рута провожу. Будет ли это работать от локального пользователя не проверял, но думаю, что нет.

npm install --global gulp
npm install --global bower

Теперь в корне проекта необходимо создать файл .bowerrc для указания места загрузки всякого-разного.

{
  "directory": "resources/assets/vendor"
}

И запускаем

npm install bower

Теперь нужно проконтролировать попадание директории node_modules в файл .gitignore. Создаём bower.json примерно такого содержания

{
  "name": "Super Site",
  "version": "0.0.0",
  "description": "My superb site",
  "ignore": [
    "**/.*",
    "node_modules",
    "resources/vendor",
    "test",
    "tests"
  ]
}

Если лень его создавать руками, можно запустить процесс его умной генерации

bower init

И добавить нужные пакеты, наборы и компоненты в bower.json

bower install jquery --save
bower install bootstrap-sass --save
bower install fontawesome --save
bower install bootswatch --save

Это богатство установится по указанному ранее пути. Если bower.json заполнялся полностью вручную, то нужно выполнить команду

bower update

Таким образом собрано всё, что должно быть обработано. По мене необходимости можно добавлять или удалять что-либо. Теперь к настройке собственно gulp.

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

    "bootstrap-sass": "^3.0.0"

из файла package.json. Важно не забыть убрать запятую в предшествующей строке. Иначе будут ошибки при чтении json файла. И запускаем

npm install

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

Это позволит избежать проблем с кэшированием подключаемых файлов при отладке. И последний штрих: донесение до gulp своих пожеланий. У всех они разные, но возможно всё. На автомате файлы могут копироваться, сливаться, обрабатываться препроцессорами, минифицироваться и всё это может происходить как по требованию, так и по факту внесения изменения в исходники.

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

├── resources
|   └── assets
|       ├── sass
|       |   └── style.sass
|       └── vendor
|           ├── bootstrap-sass
|           ├── font-awesome
|           └── jquery
|
├── public
    └── assets
        ├── css
        ├── fonts
        ├── images
        └── js

Таким образом, мне нужно после каждого обновления bower копировать то, что не нуждается в последующей обработке. Обычно это картинки и шрифты. Так же сначала можно копировать минифицированные файлы стилей и скриптов, если они подключаются отдельно и процессе разработки не принимают участия. А устраивать полную сборку непосредственно перед деплоем. А можно отдельно стили и скрипты процессить. Чисто время сэкономить. Короче, сценариев очень много. Нужно научиться выбирать правильные.

В качестве теста я хочу jquery.js и bootstrap.js копировать во временную директорию, а шрифты скопировать в public/assets/fonts только когда я явно это укажу. На регулярной основе компилировать файл resources/assets/style.sass с подключенными Bootstrap и Fonf Awesome и получать style.css в public/assets/css, а из скопированных ранее во временную директорию скриптов компилировать style.js в public/assets/js. Для этого нужно отрыть файл gulpfile.js и привести его к такому виду:

var gulp = require('gulp');
var elixir = require('laravel-elixir');
gulp.task("copyfiles", function() {
  gulp.src("resources/assets/vendor/jquery/dist/jquery.js")
    .pipe(gulp.dest("resources/assets/js/"));
  gulp.src("resources/assets/vendor/bootstrap-sass/assets/javascripts/bootstrap.js")
    .pipe(gulp.dest("resources/assets/js/"));
  gulp.src("resources/assets/vendor/bootstrap-sass/assets/fonts/**")
    .pipe(gulp.dest("public/assets/fonts"));
  gulp.src("resources/assets/vendor/font-awesome/fonts/**")
    .pipe(gulp.dest("public/assets/fonts"));
});
elixir(function(mix) {
  // Combine scripts
  mix.scripts([
      'js/jquery.js',
      'js/bootstrap.js'
    ],
    'public/assets/js/script.js',
    'resources/assets'
  );
  // Compile Sass
  mix.sass('style.sass', 'public/assets/css/style.css');
  mix.version(['assets/css/style.css', 'assets/js/script.js']);
});

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

/* Style SASS */
@import url(http://fonts.googleapis.com/css?family=Roboto)
@import url(http://fonts.googleapis.com/css?family=Roboto+Slab&subset=latin,cyrillic-ext)
/* Bootstrap */
@import "../vendor/bootstrap-sass/assets/stylesheets/_bootstrap-compass.scss"
@import "../vendor/bootstrap-sass/assets/stylesheets/_bootstrap.scss"
/* Font Awesome */
@import "../vendor/font-awesome/scss/font-awesome.scss"

Теперь при выполнении команды gulp copyfiles, будет производиться копирование шрифтов и скриптов. А при запуске gulp будет компилироваться файл стилей style.css и скрипты будут “сцепляться”. Я намеренно прописал пути явно, а не через переменные, чтобы было понятно, откуда, что и куда. Если хочется при каждом изменении исходников стилей запускать процесс компиляции, запускаем волшебную команду gulp watch. Вот вкратце и всё. Далее нужно просто создать свой сценарий, настроить его, добавить нужное, удалить лишнее и разрабатывать, разрабатывать и разрабатывать.

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

gulp --production

И немного радости в конце статьи. Все эти действия необходимо совершать только на инстансе, настроенном под разработку фронтенда. Другие версии и продакт могут просто своевременно получать готовые минифицированные версии файлов style.css и script.js, которые заранее в нужных местах прописаны. Как это будет происходить, дело исключительно внутреннее. Хоть через git, хоть с помощью флэшек. Главное, чтобы техпроцесс не нарушался.

Вообще существует два базовых подхода при создании версий сайта для мобильных терминалов:

• Отдавать разным устройствам разные версии сайта
• Заставить один сайт адаптироваться под разные устройства вывода

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

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

На роль базового фреймворка для фронтенда я вижу двух кандидатов: Foundation и Bootstrap, так же известный как Twitter Bootstrap и я его так и буду звать, т.к. бутстрепов развелось много и можно просто запутаться. Такая вот развилка возникает передо мной уже не в первый раз и я каждый раз склоняюсь к Foundation и… выбираю Twitter Bootstrap. Связано это, как правило, с его поддержкой какой-нибудь соседней технологией. Twitter Bootstrap кажется менее продвинутым и более кондовым. Вот и сейчас я тоже, кажется, выбираю не Foundation. Laravel просто вынуждает пользоваться Twitter Bootstrap на начальном этапе, а потом уже нет смысла переходить на что-нибудь другое.

Таким образом стек технологий выглядит просто и незатейливо:

• Laravel
• Twitter Bootstrap
• jQuery
• Font Awesome
• SASS
• Gulp
• И кажется, Elixir
• Оп-с, Bower
• Модули Node.js?
• Ну что ещё?..

Кажется здесь совсем не так просто, как я надеялся в самом начале. Проект разрастается до неприличия. Говорят Лужкову принадлежала технология: “Хочешь похоронить что-либо – укрупняй”. Нет ли тут риска закопаться и пропасть?