SL и Авторизованный юзер

[Redjik]

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

echo OurSuperApp::getSuperAuthManagerService()->getUser()->username

и как это сделать без SL?
в каждый шаблон пихать $user? или делать UserAwareViewFactory?

это вообще красиво решается?

 

[AmdY]

У вьюхи может быть метод, который готовит базовый шаблон вроде ларавеловского https://laravel.com/docs/5.2/views#view-composers

 

[Redjik]

ну то есть через ViewFactory пихать, не грязновато ли всегда юзера пихать, даже туда, куда не надо?

ЗЫ. некоторые дурацкие фв (не знаю пофиксили это в Yii) еще и при обращении к authManager сессию открывают (Laravel даже не смотрел еще на эту тему)
другими словами в Yii, такой запрос через SL открывал сессию год назад
Yii::$app->authManager->isGuest();

 

[AmdY]

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

view()->composer(
    ['profile', 'dashboard'],
    'App\Http\ViewComposers\MyViewComposer'
);
view()->composer(
    ['frontpage'],
    'App\Http\ViewComposers\UserProfileComposer'
);

 

[Adelf]

По мне так пихать юзера через вьюкомпозеры в шаблоны сам бог велел

 

[Redjik]

о погодите, там можно что ли для базового шаблона это указать?
окееей, вот это круто в ларавеле сделано, правда боюсь смотреть на реализацию внутри =))

 

[artoodetoo]

Помоему это ужасно К тому же не избавляет от тех же косяков с открытием сессии, если вам нужен user, а ваш AuthManager в ней нуждается.

 

[Redjik]

Критикуешь? Предлагай =)
Я специально в теории создал тему, своими мыслями поделился, вижу два варианта
1) sl
2) ViewComposer (InjectingDataViewFactory)

 

[artoodetoo]

Критикуешь? Предлагай =)

Считаю что будет разумным компромиссом сделать View Composer не порождающего лишний сервис, а дергающего SL, раз уж он есть. Кого мы обманываем?!
Сайд-эффект добывания пользователя оставим как есть.

Вариант 1:
Инициировать композер нужными именами данных, а не именем неведомого класса-посредника.
+ наглядность

view()->composer(
['profile', 'dashboard'],
'user'
);
view()->composer(
'frontpage',
['someshit', 'strangething']
);

Вариант 2:
Инициировать композер списком чего позволено тянуть из представления, просто определяем песочницу.
+ нафиг нам лишние знания про то какой именно шаблон попросит пользователя! просто разрешим это.

view()->optional(['user', 'someshit', 'strangething']); // names in our SL

А в представлении тянуть.

$user = $view->get('user'); // raise exception if not permitted

Какой для этого будет синтаксис в шаблоне, неважно. В blade это может выглядеть как @get('user')

 

[AmdY]

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

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

 

[Redjik]

@AmdY, одна поправка только к твоему куску кода у меня
не

'App\Http\ViewComposers\MyViewComposer'

а все же

App\Http\ViewComposers\MyViewComposer::class

как минимум сторм предупредит в случае опечатки

 

[artoodetoo]

Первый вариант не объясняет откуда эти переменные бурутся

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

Наличие имени лэйаута очень важный момент, который позволяет грузить только нужные данные

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

да и действий может быть больше чем просто определение какой-то переменной.

Например?

 

[Adelf]

@artoodetoo, например для сайта конференции, вверху надо список уже проведенных конференций со ссылками на архивы. Эта инфа, допустим, берется из базы. И нужна она только лэйауту.
И вообще, что за дурацкая привычка, с этими сервис-локаторами по именам. Меня эта фраза ->get('user') убивает. Эта олдскульная PHP-привычка динамически доставать все через строковые ключики. Кстати 'App\Http\ViewComposers\MyViewComposer' - в ту же тему. Нужно как можно больше статики в приложениях иметь. Чтобы по Find usages в IDE находились ВСЕ использования данного метода, поля и т.д.
Также с сервисами. Есть интерфейс, какой-нибудь IAuthService. Вот его реализацию проси и используй. Вместо ничего не говорящего 'user' или 'auth'

BTW, я в laravel приложениях держу файлик misc/blade_helper.php содержимое, которого примерно такое:

$client = new \App\Domain\Clients\Client();
$currentClient = new \App\Domain\Clients\Client();
$course = new \App\Domain\Clients\Courses\Course();
$event= new \App\Domain\Events\Event();

Я получаю авто-комплит PhpStorm'a по "{{$client->" в blade-файлах + Find usages найдут использование свойств и методов в шаблонах.

 

[artoodetoo]

А меня убивает, когда что-то кодируется ради подсказок IDE и только ради них )))
[ хотя сам тоже что-то такое использую, но это неправильно, ай-ай-ай, плохой мальчик! ]

 

[Adelf]

Дело не столько в подсказках, а в возможности отыскать все хвосты.

 

[fixxxer]

Если не "пихать в шаблоны" в экшенах контроллеров, а выделить presentation layer, вопрос отпадает сам собой.

Model::where(foo)->where(bar) писать разучились, почему бы не разучиться писать и view(['foo' => ..., 'bar' => ...])?

(А blade - фигня, это вообще не template engine, а примитивный макропроцессор, не понимаю, зачем себя так мучать).

 

[Adelf]

@fixxxer, ты давай примером научи. ткни где в гитхабах так красиво сделано.

 

[fixxxer]

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

 

[Yoskaldyr]

а выделить presentation layer

почему бы не разучиться писать и view(['foo' => ..., 'bar' => ...])

А пример кода можно? Или может где-то на гитхабе есть неплохая реализация?

 

[Redjik]

https://github.com/pmjones/adr
но тут больше в сторону не хардкодить названия вьюх