Чуть больше чем просто блог :)

Изменение файловой структуры

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

Именно проработкой структуры будущей системы управления контентом мы и займемся в данном посту.

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

Хочу отметить, что этот пост не про архитектуру  (например: Layered, Broker, Model-View-Controller, Client-Server). В этом понимании я буду использовать MVC - Модель Вид Контроллер. А это именно архитектура папок и файлов.

 

Основные принципы хорошей архитектуры:

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

Гибкость: как уже писал выше - архитектура не строится за один день, она постоянно меняется. И от того, на сколько гибким будет код тем меньше проблем и ошибок вызовет даже кардинальные изменения архитектуры.

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

Масштабируемость процесса разработки: Для ускорения написания приложения приглашая новых разработчиков к проекту.

Тестируемость: легко тестируемое приложение сделано как правило проще, легче понять более продуманно и как правило более популярно и дружественно.

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

 

Видение общей картины:

Для наглядности сделал изображение основополагающей архитектуры к проекту BeeCMS

beecms-arhitect

 

Теперь можно приступать...

В базовом приложении, на момент написания статьи, есть папка "commands" с находящимся в ней контроллером "HelloController.php". Я его использовать не буду и просто удаляю их. Перед удалением проверите нигде ли он не используется в проекте.

 

Перемещение папки VENDOR

На изображении выше видим, что папка "vendor" размещена по пути "components\core\vendor". Для этого создадим эти папки и переместим в них папку "vendor". После чего снова добавим в исключение эту папку и обновим путь к ней как к системной. Подробнее расказывал на: http://seroed.intfom.com/programirovanie/yii2/item/251-pervonachalnye-nastrojki-sajta-na-yii2

Теперь нужно указать новый путь к папке "vendor" в массиве конфига. Для этого открываем файл "/config/web.php" и добавляем строку:

'vendorPath'     => dirname(__DIR__) . '/components/core/vendor',

в корне массива "$config" на том-же уровне, на котором и "'id' => 'basic',".

Затем открываем файл "/yii.php" и заменяем пути к файлам:

require(__DIR__ . '/vendor/autoload.php');
require(__DIR__ . '/vendor/yiisoft/yii2/Yii.php');

на

require(__DIR__ . '/components/core/vendor/autoload.php');
require(__DIR__ . '/components/core/vendor/yiisoft/yii2/Yii.php');

И последнее что нужно сделать - это обновить путь к файлам автозагрузки и фреймворку в файле "/web/index.php":

require(__DIR__ . '/../vendor/autoload.php');
require(__DIR__ . '/../vendor/yiisoft/yii2/Yii.php');

на

require(__DIR__ . '/../components/core/vendor/autoload.php');
require(__DIR__ . '/../components/core/vendor/yiisoft/yii2/Yii.php');

Теперь обновляем страницу http://bee-cms.local/ и видим, что у нас ничего не изменилось. Отлично, значит мы все сделали верно.

 

Займемся переносом папки "controllers":

В ней находится только файл "SiteController.php". Именно этот класс сейчас создается при открытии сайта вызывая различные методы "action...", которые рендерят пользователю нужный вид.

Сделаем, пока в качестве заглушки, компонент "main" который будет содержать папку "controllers" в которую переносим существующий класс "SiteController". Класс будет этот-же. Мы его просто переименуем и перенесем для реализации нашей иерархии проекта.

Переименовываем файл "SiteController.php" в "MainController.php". Затем уже в переименованном файле переименовываем класс на такое-же "MainController" и указываем новое пространство имен:

namespace app\components\main\controllers;

 

Изменим в правилах "urlManager->rules" нашего конфигурационного файла "/config/web.php" вместо:

'rules' => [
    '' => 'site/index',
    '<action>'=>'site/<action>',
],

на

'rules' => [
    '' => 'main/index',
    '<action>'=>'main/<action>',
],

В этом же файле ищем массив:

'errorHandler' => [
    'errorAction' => 'site/error',
],

и заменяем на:

'errorHandler' => [
    'errorAction' => 'main/error',
],

В этом же файле конфигурации нужно указать новый путь к пространству имен контроллера по умолчанию. Для этого вставим строку:

'controllerNamespace' => 'app\components\main\controllers',

на уровне "'id' => 'basic',".

 

Подготовим еще наш вид к переносу в компонент. Заходим в папку "views" и переименовываем папку "site" на "main" - под название нашего контроллера.

И в файле "views/layouts/main.php" исправляем все ссылки типа "/site/index" и другие на "/main/index".

 

После обновления страницы мы все так-же не должны заметить никакой разницы.

 

Исключением будет страница: "contact", поскольку на этой странице идет проверка корректности ввода капчи используя виджет "Captcha" в которой по умолчанию свойство $captchaAction = 'site/captcha'; Капчи я на особо люблю и меня даже от них крутит. Не люблю я их в общем. Поэтому я просто пока сотру строку:

<?= $form->field($model, 'verifyCode')->widget(Captcha::className(), [
    'captchaAction' => 'main/captcha',
    'template' => '<div class="row"><div class="col-lg-3">{image}</div><div class="col-lg-6">{input}</div></div>',
]) ?>

в файле "views\main\contact.php".

и заодно почищу строки самой модели "models\ContactForm.php" от проверки на капчу и самого поля капчи. Получится следующее:

<?php

namespace app\models;

use Yii;
use yii\base\Model;

/**
 * ContactForm is the model behind the contact form.
 */
class ContactForm extends Model
{
    public $name;
    public $email;
    public $subject;
    public $body;


    /**
     * @return array the validation rules.
     */
    public function rules()
    {
        return [
            // name, email, subject and body are required
            [['name', 'email', 'subject', 'body'], 'required'],
            // email has to be a valid email address
            ['email', 'email'],
        ];
    }

    /**
     * Sends an email to the specified email address using the information collected by this model.
     * @param string $email the target email address
     * @return boolean whether the model passes validation
     */
    public function contact($email)
    {
        if ($this->validate()) {
            Yii::$app->mailer->compose()
                ->setTo($email)
                ->setFrom([$this->email => $this->name])
                ->setSubject($this->subject)
                ->setTextBody($this->body)
                ->send();

            return true;
        }
        return false;
    }
}

 

Осталось еще изменить ссылки, пока демонстрационного, верхнего меню. Открываем "views\layouts\main.php" и меняем ссылки "/site/..." на "/main/...".

 

Ну что ж, первые шаги на пути к изменению файловой структуры положены. Существующие модели: "ContactForm" "LoginForm" и "User" пока трогать не будем, поскольку они так-же требуют отдельных компонентов по типу "Main". Но это уже следующие истории :)

Другие материалы в этой категории: « Настройка подключения и работа с GitHub через PhpStorm

Оставить комментарий

Убедитесь, что вы вводите (*) необходимую информацию, где нужно
HTML-коды запрещены

Авторизация