Вопросец yii'стам, ну и симфонисты тоже загляните?

Question

[AlikDex]

Извиняйте что так не информативно. Просто не знаю как озвучить вопрос.
В общем тема такая. Сидел я значит думал думал. Не нравятся мне всякие Yii::$app->params['site_title'] массивы для настроек. Уныло и нудно в шаблонах прописывать постоянно такое. Запилил короче свои настройки с блудницами. Через класс, ну и подключил через компоненты. Получилось еще более унылое зрелище: Yii::$app->settings->get('site_title');
Вот. Подкрадываемся к сути вопроса. Вот если заинжектить этот объект с настройками в объект View? ну типа чтоб в шаблоне было $this->settings->get('site_title');. Нормально не? Какие подводные камни? Или в принципе идея г-но? Что по этому поводу скажут симфонисты, очень уж интересно, как они справляются с подобными ситуациями (когда нужен глобальный конфиг)? Или может вообще лучше статический класс сделать.

Answer 1

[Максим Федоров]

Не нравятся мне всякие Yii::$app->params['site_title'] массивы для настроек.

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

ну типа чтоб в шаблоне было $this->settings->get('site_title');. Нормально не?

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

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

Comments

[AlikDex]

Максим Федоров:

Насколько я понимаю Вы хотите вынести настройки title всех страниц в единый файл настроек

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

[Максим Федоров]

AlikDex: тут нужно выбирать способ реализации только от конкретной задачи. Т.е. брать задачу и думать как внедрять необходимые параметры.
Реализация какого-то универсального класса с параметрами ведет к тем же проблемам что Yii::$app->params, разница будет лишь только в том что Вы будете работать не с массивом а объектом

[AlikDex]

Максим Федоров: Задача простая в принципе. Иметь глобальный конфиг приложения с хранением параметров в бд например. И какой-то стандарт использования этого конфига(для себя, разумеется).

В общем что-то типа https://github.com/phemellc/yii2-settings
Вот только этот Yii::$app->settings там тоже таскается везде.

[Максим Федоров]

AlikDex: если Вы хотите иметь глобальный конфиг - тогда смиритесь с тем что его придется таскать, иначе это уже будет не глобальный конфиг

[AlikDex]

Максим Федоров: так может его через DI цеплять, или через локатор. Просто там где нужен. Пример привел у Максима Тимофеева в комментарии. Условно конечно, но как-то так.

Дело не ограничивается только сеттингами. Иногда нужен Request во вьюхе. Например на странице поиска отобразить что-то типа "Вы искали: " . Yii::$app->request->get('q'), где q это запрос пользователя.
Возможно контент контейнер, офрмленный в виде класса с содержимым для страницы

[Максим Федоров]

AlikDex:

так может его через DI цеплять, или через локатор.

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

Иногда нужен Request во вьюхе.

А вот это не правильно. Вьюха не должна знать о запросе, это нарушение MVC

[AlikDex]

Максим Федоров:

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

И как быть? Настройки эти нужны иногда и в модулях (которые в свою очередь могут свои настройки иметь). Т.е. туда тоже по идее надо инжектить как-то автоматом при инциализации модуля. Причем если нужно будет иметь к примеру отдельные для модуля настройки, то их вообще отдельно грузить. Но при этом хранить в тойже таблице что и основные (структура которой что-то типа module_id | name | value, чтоб не пересекались основные и модульные настройки).

Answer 2

[Максим Тимофеев]

Получилось еще более унылое зрелище

Почему? Я так же с настройками работаю. Храню в базе, кеширую и т.д. Удобно.

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

Comments

[AlikDex]

Максим Тимофеев:

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

Не привязать к вьюхе, а просто создать свойство у вью объекта с содержимым сеттинг компонента. т.е. сам компонент никуда не девается. Он как был так и остается. Небольшой пример:

<?php
namespace app\components;

use Yii;

/**
 * Base Class for View
 */
class View extends \yii\web\View
{
    public $settings = 'settings';
    /**
     * @inheritdoc
     */
    public function init()
    {
        parent::init();

            // Set settings component
        $this->settings = Instance::ensure($this->settings, 'app\components\Settings');
    }
}

И от него уже наследоваться.

[Максим Тимофеев]

AlikDex: Вы не поняли. Вам где-то нужно вытянуть настройку, данные. Для этого вы будете тянуть экземпляр view c экземпляром settings. То есть дергать больше логики, чем надо. Это как сделать 1 модель, которые в себе содержит все другие модели. Это не имеет смысла. От этого нет пользы, а производительность теоретически просядет, пусть и на мизер какой-то, но зачем? Не вижу изюма в этом.
Допустим есть ajax контролер, который отдает только данные и где-то его логика завязана на ту или иную настройку или в моделе Вы имеете метод зависимый. Будете обращаться к view из модели, как к статике, что бы получить настройку?

[AlikDex]

Максим Тимофеев:

Вы имеете метод зависимый. Будете обращаться к view из модели, как к статике, что бы получить настройку?

Нет, в базовую модель тоже засуну, и в контроллер. Может быть $this->settings будет содержать ссылку на подключенный компонент(который в свою очередь также будет доступен через Yii::$app->settings. Тогда оверхеда не должно быть.

[Максим Тимофеев]

AlikDex: Тогда будет дублирование логики. Зачем все это? Смысл? Может быть это и нужно, но я не вижу ни одного повода так делать. Объясните.

[AlikDex]

Максим Тимофеев: просто стандарт для себя. Форма записи. как-то через $this->settings воспринимается лучше. Хрено его знает, но Yii::$app категорически не нравится. Как бы велосипед не изобретаю, подобные мысли и раньше посещали других людей, правда с другими штуками, но тем не менее: https://github.com/yiisoft/yii2/issues/13922
Собственно, и набрел на этот топик из-за того, что надоело постоянно в контроллерах писать $request = Yii::$app->request;. Да и потом, при рефакторинге или бегать по всем контроллерам\моделям\вьюхам
менять, или у базовых классах изменить способ внедрения (может вообще через аргументы конструктора передавать понадобится)

[Максим Тимофеев]

Yii::$app многим не нравится, но от того что Вы сделаете он никуда не пропадет. Он все равно будет
С request дело обстоит иначе. Это же не неотъемлемая часть контроллера, и в yii 2.1 это переделают: https://github.com/yiisoft/yii2/issues/13922
Дело не в $this вовсе. Не в красивости конструкции. Тут под $this подразумевается класс контроллера и обсуждают, что так как request не должен использоваться за его пределами, то и логично его встроить в этот класс.
А у Вас полностью независимый компонент, который можно использовать где угодно. Не стоит сравнивать. И тем более во view пихать его странно.
Так что мне кажется Yii::$app->settings самый правильный вариант из возможных. Пока не будет переделан весь yii, а в этом аспекте, я думаю не раньше версии 3. А она будет не скоро. Пока в планах видел только 2.1 и совсем не понятно когда 2.2

[AlikDex]

Дело не в $this вовсе. Не в красивости конструкции. Тут под $this подразумевается класс контроллера и обсуждают, что так как request не должен использоваться за его пределами, то и логично его встроить в этот класс.
А у Вас полностью независимый компонент, который можно использовать где угодно. Не стоит сравнивать. И тем более во view пихать его странно.

Сдается мне, что этот реквест так и останется в компонентах глобальным, в 2.1 версии, и никуда не денется Ну не в этом суть. Нужен какой-то стандарт, но при этом избежать использования Yii::$app. Одно дело когда ты пару сайтов делаешь, другое когда 20 уже есть, и 20 еще на подходе. Потом бегать по всем и исправлять по всем это какой-то ад будет.

Изначально вообще так делал:

<?php
namespace app\bootstrap;

use Yii;
use app\models\Setting;

/*
/* The base class that you use to retrieve the settings from the database
*/
class Settings implements \yii\base\BootstrapInterface
{
    /**
    * Bootstrap method to be called during application bootstrap stage.
    * Loads all the settings into the Yii::$app->params array
    * @param Application $app the application currently running
    */
    public function bootstrap($app)
    {
        // Get settings from database
        $settings = Setting::find()
            ->all();

        // Now let's load the settings into the global params array
        foreach ($settings as $val) {
           if ($val['module_id'] === '') {
               Yii::$app->params[$val['name']] = $val['value'];
           } else {
               Yii::$app->params[$val['module_id']][$val['name']] = $val['value'];
           }
        }

    }
}

Юзал Yii::$app->params[] и горя не знал )) С этой точки зрения что отдельный компонент, что парамсы все едино, т.к. результат одинаковый, отличается только форма записи.

[Максим Тимофеев]

2.1 мажорная версия без обратной совместимости. Железобетонно будут убирать. И еще кучу чего, так что простого update до версии 2.1 не ждите
например в 2.2 Yii::getAlias() и другие методы вынесут в хелперы, будет FileHelper::getAlias()
Вот тут расписано, что нас ждет:
https://github.com/yiisoft/yii2/wiki/Plan-for-next...
И это отлично как по мне. Что бы не тягать лапшу от версии к версии, как это было с yii1

По поводу настроек, надо кешировать. Зачем при каждом запросе в базу лезть и метод get тоже нужен, что бы пустую строку возвращал, если настройки такой нет, а не ошибку кидал. И нет ничего в этом Yii::$app->settings->get('code') страшного, я так же использую. Автокомплит поставьте для своей ide и вообще напрягать не будет.

[AlikDex]

2.1 мажорная версия без обратной совместимости. Железобетонно будут убирать. И еще кучу чего, так что простого update до версии 2.1 не ждите

Потому и переписал все контроллеры также: https://github.com/yiisoft/yii2/issues/13922#issue...
И использую $this->request. Потом просто перепишу конструктор и все, и не бегать по всем методам как дурачок ) Потом подумал, почему с другими необходимыми компонентами не сделать тоже самое?

[Максим Тимофеев]

AlikDex: А зачем обновлять старые проекты. Если они работают на yii 2.0* пусть и работают. Да и как по мне - это преждевременная паника. Еще не известно окончательно что и как там будет. Еще 100 раз поменяться все может. Сизифов труд.

[AlikDex]

Максим Тимофеев: за тем что они мои и нужно поддерживать постоянно ) Если на всех будет разная версия, то рано или поздно башка поедет.

[Максим Тимофеев]

AlikDex: Тогда да. Я думал Вы лендинги сделали кому-то и потом им версии yii обновляете своевременно и безвозмездно )))
Но все равно это слишком преждевременно. Проще делать модульно, модули хранить на github например, подключать через компосер, потом внесли правки, запустили им update.