2013-03-05 1 views
0

Я создал класс обработчика, который происходит от AbstractProcessingHandler. Я видел, что могу поместить его в src/MyNamespace/MyBundle/Monolog/, но меня это немного беспокоит, потому что этот обработчик используется в нескольких других пакетах, где я регистрирую данные. Поэтому для других пакетов потребуется, чтобы MyBundle работал правильно, только из-за этого обработчика.Где я должен поместить свой пользовательский обработчик Monolog в мой проект Symfony2?

Я попытался поставить класс обработчика в lib/, но он не работает (возможно, мне нужно сделать что-то особенное с Autoload?).

Или мне нужно создать новый пакет специально для этого обработчика?

Редактировать: Я не могу поместить свой собственный класс обработчика в vendor/monolog/monolog/src/Monolog/Handler, потому что тогда я не смог бы добавить его в свой репозиторий git: есть конфликт, потому что эта папка управляется другим репозиторием git (созданным Composer)

ответ

2

На конце монолога там действительно нет ограничений на том, где поставить его или как вы это называете , Ключ состоит только в том, что он реализует свойство HandlerInterface монолога или распространяется от одного из существующих обработчиков.

Теперь это зависит от вашего обработчика, если это общий материал, который могут использовать другие люди, вы можете отправить его в качестве запроса на вытягивание монолога.
Если нет, вы можете создать для него собственный пакет композитора или поместить его в src/Acme/Monolog/FooHandler или что-то в этом роде, чтобы он оставался в вашем приложении, но явно из комплекта. Недостатком является то, что вам нужно настроить его как услугу в одном из ваших пакетов, так что у вас все еще есть какая-то зависимость от пакета.
Возможно, это будет иметь смысл в его собственном пакете. Но это довольно много шаблонов только для одного класса.
Если все ваши пакеты являются специфичными для приложения и вряд ли будут извлечены из него, наличие зависимостей между связями отлично, хотя ИМО.
Зависимость в любом случае не очень сильная, так как один пакет может содержать обработчик и настраивать его. Другие пучки могут записываться в монолог, даже если обработчик отсутствует, они могут регистрироваться. Он просто не подходит к этому конкретному обработчику. Ничего не должно сломаться.

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

0

Если вы хотите, чтобы ваш класс обработчика находился в lib/, вам необходимо добавить папку lib/ в раздел автозагрузки composer.json. Например:

"autoload": { 
    "psr-0": { "": ["src/", "lib/"] } 
} 

Посмотрите на документацию Композитор:

Basic Usage

Autoload

0

Я думаю, что общий подход здесь заключается в использовании «Bridge» в вашем комплекте с явной зависимостью. Если у вас есть другие пакеты, которые полагаются на это, то, что мы сделали, это создать ServiceBundle, который в основном предназначен для всех общих служб во всех пакетах приложения. Это может не сработать для вас, если у вас есть планы распространения этого пакета, но в противном случае.

Смежные вопросы