Dmitry Malinov (0) увеличил репутацию Trekov (1)

всегда бы так

Еще вопрос в плане namespace'ов. Мы можем обратиться к какому-то статическому методу/констате/статической переменной прописав namespace, допустим: \app\models\SomeClass::SOME_CONTANT А можно использовать use app\models\SomeClass, и уже получать напрямую через SomeClass::SOME_CONTANT не прописывая классов. Какой подход где лучше применять?

Допустим, я на странице хочу обратиться к двум константам: \app\models\SomeClass::SOME_KEY \app\models\SomeClass::SOME_DIGIT При таком подходе много места занимает немспейс класса, и лучше use прописать, так?

use лучше всегда использовать

но не всегда возможно

многие любят использовать частичный use

многие любят использовать частичный use

"частичный use" — это как? (google молчит)

use \app\models

Еще вопрос в плане namespace'ов. Мы можем обратиться к какому-то статическому методу/констате/статической переменной прописав namespace, допустим: \app\models\SomeClass::SOME_CONTANT А можно использовать use app\models\SomeClass, и уже получать напрямую через SomeClass::SOME_CONTANT не прописывая классов. Какой подход где лучше применять?

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

но не всегда возможно

Спасибо. Невозможно из-за вероятности одинаковых наименований класса? К примеру: app\models\User app\components\User

use \app\models

Понял, спасибо.

когда импортируешь 2 одинаковых класса важно задать алиас (use Some as ConcreteSome)

когда импортируешь 2 одинаковых класса важно задать алиас (use Some as ConcreteSome)

О, спасибо, понял теперь зачем эти алиасы ? А в плане памяти сильную роль играет импорт и обращение к конкретному адресу? Можно ли жертвовать чуть ей ради чистоты кода?

Не думаю что есть большая разница

ты ведь на пхп пишешь, небось даже не демонов

Демонов проще писать)

И еще хотел бы по MVC уточнить: Допустим, у нас есть меню, в котором мы желаем отображать число, например, активных тикетов. И есть модель, которая наследует ActiveRecord. Является ли плохой практикой формирования запроса AR прямо во view? <a href='#'>Тикеты [<?= Ticket::find()->where(['status' => Ticket::STATUS_NEW])->count()?>]</a> Или для этого лучше создавать какого-то рода виджет?

И еще хотел бы по MVC уточнить: Допустим, у нас есть меню, в котором мы желаем отображать число, например, активных тикетов. И есть модель, которая наследует ActiveRecord. Является ли плохой практикой формирования запроса AR прямо во view? <a href='#'>Тикеты [<?= Ticket::find()->where(['status' => Ticket::STATUS_NEW])->count()?>]</a> Или для этого лучше создавать какого-то рода виджет?

Очень плохо, очень, за такое руки отрывают у нас, как у других не знаю)

Очень плохо, очень, за такое руки отрывают у нас, как у других не знаю)

Каков выход? Виджеты? Ну на примере того же Yii2(в нем также MVC, есть виджеты для HTML-блоков). Спасибо за ответ. Просто, хочу понять как правильно реализовать, по-сути тут даже в Controller не передается, потому что меню на всех страницах.

опять этот yii

Каков выход? Виджеты? Ну на примере того же Yii2(в нем также MVC, есть виджеты для HTML-блоков). Спасибо за ответ. Просто, хочу понять как правильно реализовать, по-сути тут даже в Controller не передается, потому что меню на всех страницах.

почитай чего на тему разделени ответственности.

и да у тебя может быть не только "вьюшки", "модельки AR" и "контроллеры".

И еще хотел бы по MVC уточнить: Допустим, у нас есть меню, в котором мы желаем отображать число, например, активных тикетов. И есть модель, которая наследует ActiveRecord. Является ли плохой практикой формирования запроса AR прямо во view? <a href='#'>Тикеты [<?= Ticket::find()->where(['status' => Ticket::STATUS_NEW])->count()?>]</a> Или для этого лучше создавать какого-то рода виджет?

как минимум ты можешь запихнуть все что относится к построению запроса в метод "модели"

а вообще в идеале тебе в шаблон уже готовые данные должны приходить, без необходимости что-то там догружать.

И еще хотел бы по MVC уточнить: Допустим, у нас есть меню, в котором мы желаем отображать число, например, активных тикетов. И есть модель, которая наследует ActiveRecord. Является ли плохой практикой формирования запроса AR прямо во view? <a href='#'>Тикеты [<?= Ticket::find()->where(['status' => Ticket::STATUS_NEW])->count()?>]</a> Или для этого лучше создавать какого-то рода виджет?

При таком подходе сложно отладку делать, для изменения результата придется лазить и править вьюху, я уже не говорю о том, что вьюха должна быть независима и их можно менять, допустим отдавать json массив через вьюху или xml, соответственно данные из контроллера должны быть всегда готовы и передаваться в слой view

У меня плохо с терминологией и теоретическими знаниями архитектуры, я практик

Спасибо за ответы, буду разбираться с грамотной реализацией!

При таком подходе сложно отладку делать, для изменения результата придется лазить и править вьюху, я уже не говорю о том, что вьюха должна быть независима и их можно менять, допустим отдавать json массив через вьюху или xml, соответственно данные из контроллера должны быть всегда готовы и передаваться в слой view

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

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

Виджет это по сути layout?

Виджет это по сути layout?

не. это как подзапрос в симфони, только в Yii nам свои кастыли для этого

ну мол ты можешь в шаблоне объявить что "вот тут должна отображаться менюшка" или "топ 10 продуктов", можешь как-то параметры задать а дальше у виджета своя вьюшка, свой контроллер. Детишки называют это HMVC)

я бы генерацию меню сделал классом, а там можно его куда угодно отдавать , допустим будет он итератором, норм вроде

ну мол ты можешь в шаблоне объявить что "вот тут должна отображаться менюшка" или "топ 10 продуктов", можешь как-то параметры задать а дальше у виджета своя вьюшка, свой контроллер. Детишки называют это HMVC)

Хуки короче

Хуки короче

ммм нет, не хуки)

Евентом можно сделать

что сделать?) о чем ты?)

я бы генерацию меню сделал классом, а там можно его куда угодно отдавать , допустим будет он итератором, норм вроде

и html в этот класс бы положил?)

Событие, которое дёргает диспетчер, на который подписываются

Событие, которое дёргает диспетчер, на который подписываются

к чему ты это вообще?)

какие ивенты, кто их будет кидать? зачем?

и html в этот класс бы положил?)

Нет во вьюху отдал бы, а там html код бы уже сформировался бы... Понял о чём ты))))

минутку... пишу код, объяснить не могу словами

да не надо изобретать велосипеды)

http://symfony.com/doc/current/templating/embedding_controllers.html

вот пример

как это грамотно делается

Ну я использовал терминологию Yii2. В Yii2 виджеты многоразовые строительные блоки, которые используются в представлениях. К примеру, для генерации Navbar'а. О минусах фреймворка знаю, но раз уж взялся, тогда хочу довести до конца изучение, чтобы не бросать на полудороге и мигрировать туда-сюда. В дальнейшем Lavarel планирую освоить.

как мне мапу то описать, чтобы симфония не ругалась?

А так можно?

я что-то не уверен

в идеале получить бы либо мапу вида key=>Object, либо хотя бы key=>className

https://symfony.com/doc/current/service_container/parameters.html#array-parameters вот тут что-то похожее

Вот я тоже думаю что так нельзя

Так это параметры

типа отдельно нужно описать параметры и потом в аргументах отсылку к ним приделать?

возможно, попробуй так

даже в том же файле, просто в секции parameters

понял, сейчас попробую

Все равно не выйдет я думаю

ну судя по доке - может получиться

Ну посмотрим что выйдет у него, но ставлю что нет)

вообще лучше бы ты скинул конкретную ошибку, а то есть мнение, что ты просто конфиг неправильно написал, если там аргументы - там вроде массив надо, если хочешь конкретный указать - надо знак бакса

Вообще если цель держать в сервисе заполненный массив других сервисов можно через compiler pass разрулить

ERROR: S client not available

вообще лучше бы ты скинул конкретную ошибку, а то есть мнение, что ты просто конфиг неправильно написал, если там аргументы - там вроде массив надо, если хочешь конкретный указать - надо знак бакса

Я как понял он хочет передать массив из сервисов в конструктор

Я как понял он хочет передать массив из сервисов в конструктор

я хочу передать туда хотя бы массив из строк с ключами

если удастся передать массив из сервисов, будет еще лучше

А, массив из строк тогда не проблема, как параметр объяви

Должно сработать такое

Если массив из сервисов хочешь попробуй через compiler pass

если удастся передать массив из сервисов, будет еще лучше

сделай объект, который будет тебе возвращать нужный объект по переменной =\

ты же всё равно в массиве будешь по ключу искать

короче оберни массив в класс =)

теперь другая проблема: для DefaultHandlerFactory объявил интерфейс ContainerAware, приделал трейт ContainerAwareTrait, но контейнер туда не подсунулся

а это с чем может быть связано?

а это с чем может быть связано?

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

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

да хз, просто вроде из коробки есть, и даже как-то раз запустилось

а потом перестало О_о

да хз, просто вроде из коробки есть, и даже как-то раз запустилось

Передавай как зависимость через конструктор, это более явно

А вообще если я правильно понял что ты хочешь. То тебе можно выдать тег твоим сервисам и через compiler pass их собирать и уже отдавать в методе resolve

Вот тут есть примерчик https://symfony.com/doc/current/service_container/tags.html

ну вариант с явным массивом мог бы быть даже интереснее в некоторых ситуациях

но да, компайлер пассом такое разруливается на ура

ну хотелось бы таки получить массив объектов, чтобы не дергать конейнер и не объявлять дефиниции как паблик

ну с компайл пассом получится слишком чисто - аж магически)

ну магия это тоже грязь какая-то, магии я в Yii наелся)

А так можно?

можно

только если хочется сервис то там должна быть собачка

ну и я бы это дело в локатор все ж завернул)

хотя... почему бы и нет

Чуваку надо просто массив сервисов в конструктор передать)

На кой ляд ему локаторы, компайл-пассы и классы над массивами?

вот как-то с PHP-DI таких вопросов не возникало