Лучше вообще не пытайся этим пользоваться, хуже потом будет.

fxp composer asset plugin — это аццкое зло.

я уже влип :(

В Yii2, ты ведь его пользуешь, его вообще выпилят скоро.

Они это говорят уже 3 год

Но все еще мы видим припиленный jquery

https://github.com/yiisoft/yii2-maskedinput Уже начали по чуть-чуть шевелиться.

и этот плагин.

Ну, пока не выпилили то пользуемся. Переделывать проект тлько потому что это антипаттерн ни кто не будет ?

Ну, пока не выпилили то пользуемся. Переделывать проект тлько потому что это антипаттерн ни кто не будет ?

Есть способ не тащить эту какашку в проект: https://github.com/cebe/assetfree-yii2

кстати, а как будет установка зависимостей?

Уже в 2.0.

кстати, а как будет установка зависимостей?

Самый лучший способ — это как сейчас делают в бандлах Symfony. Просто кладут CSS/JS-файлики в бандл, а там ты уже дальше сам решаешь, как их в своём проекте использовать: можешь Webpack, можешь Browserify, можешь Gulp/Grunt и так далее. Backend фреймворк ведь не должен знать о том, что и как ты с ассетами делаешь. По логике вещей. Так что пускай Yii 2.1 расширения тоже кладут эти файлики в директорию с расширением, а мы, программисты конечные, уже дальше определимся сами. Может в проекте все ассеты и всё фронтендовое вообще yarn'ом/npm'ом подтягивается и управляется? Тогда эти файлики вообще мёртвый груз.

Или даже пускай Yii 2.1 расширения создадут аналоги в npm. Ещё круче.

Чтобы прямо из npm/yarn и ставить их себе в проект.

А то, что сейчас в Yii 2.0... Там надо нехило так напильником поработать, чтобы это можно было паковать при помощи Webpack или Browserify. Не очень приятно обходить AssetManager ихний.

Да, не радужно все. Ну а вообще виден свет в конце тунеля о выпиливании зависимостей?

да виден

Ну ветка уже есть.

Хорошо в Symfony выпилили тоже Assetic.

Кому надо поставит.

так в 2.1 тоже выпилят ассет менеджер?

или только установку фронт зависимостей через композер?

Не-не, там не так будет. В самом основном репозитории не будет ничего из bower-asset или npm-asset в require-секции в файле composer.json. Вот пример будущего расширения: https://github.com/yiisoft/yii2-maskedinput/blob/master/composer.json#L22 Они все части фреймворка, которые используют bower-asset/npm-asset выносят в такие расширения и делают их опциональными. То есть если кому-то нравятся они, то да, пожалуйста, юзай чувак. ? А если не нравятся, то и не ставь их, потому что это уже не будут жёсткие зависимости в основном репозитории/пакете Yii 2.1.

Если кому-то нравится fxp composer asset plugin*

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

Его нужно вызывать из любого места. И сколько угодно раз.

И он нужен именно глобально.

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

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

Лучше инжектить как опциональную зависимость в сеттер.

Логгер твой.

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

Причём тут зависимость?

> сеттер

Его нужно вызывать из любого места. И сколько угодно раз.

вот причем

зависимость, это когда тебе что-то нужно. В твоем случае тебе нужен логгер

> сеттер

Ну, не в сеттер, а в класс. =) Но идея верная была высказана.

У меня просто статический (да, да) класс. Logger::write("Message", 3). Т.е. сообщение и уровень ошибки.

А как "правильно" организовать это?

$logger->write

вот так правильно

У меня просто статический (да, да) класс. Logger::write("Message", 3). Т.е. сообщение и уровень ошибки.

Как передаёшь контекст в статический метод write? Чтобы разделять отправку сообщений логгера в зависимости от контекста в разные места.

и $logger пробрасывать куда-нибудь в конструкторы, юзать декораторы

Ну это не суть важно я думаю. Я понимаю что некоторые тут не любят статику.

Ну это не суть важно я думаю. Я понимаю что некоторые тут не любят статику.

это суть важно

Т.е. мне в каждую функцию закидывать $logger?

Я про это.

Т.е. мне в каждую функцию закидывать $logger?

в каждый объект. Или ты под WP пишешь?

Ну это не суть важно я думаю. Я понимаю что некоторые тут не любят статику.

Мы не то что не любим, статика тут не работает. =)

Я про общие случаи.

или - декорация/AOP

И не делает то, что нужно.

Я и функционально и ООП могу писать же. Иногда мне тут советуют делать простую функцию вместо класса, а иногда говорят что нужны только классы. Я вас не пойму. ?

Я и функционально и ООП могу писать же. Иногда мне тут советуют делать простую функцию вместо класса, а иногда говорят что нужны только классы. Я вас не пойму. ?

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

@fes0r а у вас тут есть мемы?

Вот допустим есть функции, как туда $logger прокидывать? Мне как раз кажется статический класс и есть решение.

Вот допустим есть функции, как туда $logger прокидывать? Мне как раз кажется статический класс и есть решение.

функции?

как зависимость, аргументом если у тебя карирование какое

или как зависимость в конструктор класса

+

Мы же говорим про класс-логгер?

мы про пользователя говорим

Тогда я вас вообще не понимаю. ?

Мы же говорим про класс-логгер?

а потом ты начал говорить про функции какие-то

в каждый объект. Или ты под WP пишешь?

Вот.

Я и функционально и ООП могу писать же. Иногда мне тут советуют делать простую функцию вместо класса, а иногда говорят что нужны только классы. Я вас не пойму. ?

Как бы ты реализовал следуюущую задачу при помощи твоего статического метода для логгинга? Для классов A, B и C отправлять логи на мыло. Для классов C, D и E отправлять логи в Sentry. Для классов D, E и F отправлять логи в файлы. При помощи Dependency Injection решается очень просто, в твоём случае же надо городить кучу кода в статическом методе и в самих классах, которые их будут использовать. Вот тебе наглядный пример, почему это не работает.

Кучу непонятного кода.

ERROR: S client not available

Вот.

пользователь - имеется в виду тот код, который пользуется твоим логгером

Как бы ты реализовал следуюущую задачу при помощи твоего статического метода для логгинга? Для классов A, B и C отправлять логи на мыло. Для классов C, D и E отправлять логи в Sentry. Для классов D, E и F отправлять логи в файлы. При помощи Dependency Injection решается очень просто, в твоём случае же надо городить кучу кода в статическом методе и в самих классах, которые их будут использовать. Вот тебе наглядный пример, почему это не работает.

?

Тогда я вас вообще не понимаю. ?

https://gist.github.com/mkusher/c2fb335d5252b6302f630db7c758d77e

@lokin_roman, посмотри как в Symfony 3.* это делается. Да даже можно просто почитать про Pimple. Тебе и самому приятно будет потом так писать, а ещё приятнее читать этот код. ?

Вообще не увидел преимущества перед Logger::log('start'). Если мы знаем что в каждом классе и каждой функции будем использовать логгер, то какой смысл огороды с конструкторами.

выше @resurtm описал зачем

Благодарю за ответы. Буду думать. ?

Благодарю за ответы. Буду думать. ?

не будешь)

)))

?

не будешь)

Почему ты так думаешь?

Почему ты так думаешь?

ну потому что @resurtm тебе по сути привел причину почему твой способ не работает.

Реально, Dependency Injection Container очень упрощает жизнь программиста. Штука для понимания простая, а упрощает жизнь порядочно. Yii2 и даже тут отстаёт сильно. Они всё ещё до сих пор продолжают использовать Service Locator, что по сути и является тоже самое, что и использовать статические методы в классах (а по сути просто глобальные функции). И это несмотря на то, что Service Container они завезли во фреймворк очень давно.

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

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

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

у тебя вообще есть monolog

и не надо велосипедов

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

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

он должен тупо писать в лог

со статикой это невозможно

у тебя вообще есть monolog

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

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

Вместо монолога можешь сам имплементировать PSR-3. ? И будет своё, для тренировки.

И прикручивать это ко всему, что умеет PSR-3.

Я не разделяю мнение что реимплементация фреймворков приносит хоть какую-то пользу в плане обучения

Я не разделяю мнение что реимплементация фреймворков приносит хоть какую-то пользу в плане обучения

Ну, раз человек желает, то пускай потренируется. ?

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

Что значит не должен знать о контексте?

> Для классов A, B и C отправлять логи на мыло. Для классов C, D и E отправлять логи в Sentry. Для классов D, E и F отправлять логи в файлы.

вот куда слать логи - это пусть логгер как-то решает сам

Так это само собой. А у монолога не так разве? $log->pushHandler(new StreamHandler('path/to/your.log', Logger::WARNING));

Я другого варианта не предлагаю.

Ну, раз человек желает, то пускай потренируется. ?

ну то есть все зависит от того чему хочет научиться человек. Работать с файловой системой - ну тут логгеры можно пописать...

Так это само собой. А у монолога не так разве? $log->pushHandler(new StreamHandler('path/to/your.log', Logger::WARNING));

но ты это будешь делать не там где будешь его юзать а на этапе построения приложения