Комментарии 25
Посмотрел исходники и огорчен… где же PSR CodeStyle?
В чем именно отличия от PSR? В том, что "{" не переносится на новую строку в классах и методах?=)
НЛО прилетело и опубликовало эту надпись здесь
+1 Судя по всему, автор уже привёл в соответствие с PSR.
Да, формально, PSR — всего лишь набор рекомендаций.
Но, де-факто это стандарт для open-source проектов, ибо альтернатив, достаточно распространённых чтобы быть достойными внимания, в современном PHP, лично я не вижу. Раньше, да у каждого более менее крупного фреймворка был свой стандарт.
Но php — язык интерпретируемый, с широкой практикой использования вендорных библиотек и переиспользования кода вообще. Мало приятного в чтении исходников или использовании кода от третей стороны, когда в каждой либе свой огород. Всем проще и удобнее если это будет один стиль, один формат.
Вообще, PSR, на мой взгляд, один из важных и удачных аспектов развития языка.
PS: Не важно какое соглашение вы примите, важно что оно было принято©… Чистый / Совершенный Код (Мартин / Макконнелл)??
Да, формально, PSR — всего лишь набор рекомендаций.
Но, де-факто это стандарт для open-source проектов, ибо альтернатив, достаточно распространённых чтобы быть достойными внимания, в современном PHP, лично я не вижу. Раньше, да у каждого более менее крупного фреймворка был свой стандарт.
Но php — язык интерпретируемый, с широкой практикой использования вендорных библиотек и переиспользования кода вообще. Мало приятного в чтении исходников или использовании кода от третей стороны, когда в каждой либе свой огород. Всем проще и удобнее если это будет один стиль, один формат.
Вообще, PSR, на мой взгляд, один из важных и удачных аспектов развития языка.
PS: Не важно какое соглашение вы примите, важно что оно было принято©… Чистый / Совершенный Код (Мартин / Макконнелл)??
НЛО прилетело и опубликовало эту надпись здесь
Пользуясь предложенной литературной метафорой, я бы определил PSR не как разновидность авторского стиля, а скорее как общепринятую для языка пунктуацию — как мы переносим слова, ставим запятые, большие буквы в начале предложения и т.п.
Ожидать и желать чтобы повсеместно был PSR, это что-то сродни Grammar-nazi. Но не вижу в этом ничего плохого.
Авторский же стиль, это из области дизайна — нагородить абстрактных фабрик, фасадов или других абстракций, обеспечить всё публичными интерфейсами или запилить одним статическим божественным классом. Вот где стоит искать (и проявлять) индивидуальность, а не на уровне пунктуации =)
У Брукса приводится мысль, что жесткие рамки стиля не мешают, а наоборот помогают настоящему мастеру.
Ожидать и желать чтобы повсеместно был PSR, это что-то сродни Grammar-nazi. Но не вижу в этом ничего плохого.
Авторский же стиль, это из области дизайна — нагородить абстрактных фабрик, фасадов или других абстракций, обеспечить всё публичными интерфейсами или запилить одним статическим божественным классом. Вот где стоит искать (и проявлять) индивидуальность, а не на уровне пунктуации =)
У Брукса приводится мысль, что жесткие рамки стиля не мешают, а наоборот помогают настоящему мастеру.
НЛО прилетело и опубликовало эту надпись здесь
Для ошибок на уровне синтаксиса языка, я бы привёл аналогию с грамматикой, орфографией — она однозначна как в естественных, так и в искусственных языках.
Пунктуация же, строго говоря, есть формальная, для любого языка, но может быть и авторской, что распространено в литературе.
PSR при таком взгляде, это официальная пунктуация, e.g. рекомендованная «госпожой Вербицкой» (a.k.a FIG) сообщества PHP =)
PS: это как разговорный PHP и литературный. Вроде бы, да многие делают не по PSR, но в «обществе», так говорить — моветон.
Пунктуация же, строго говоря, есть формальная, для любого языка, но может быть и авторской, что распространено в литературе.
PSR при таком взгляде, это официальная пунктуация, e.g. рекомендованная «госпожой Вербицкой» (a.k.a FIG) сообщества PHP =)
PS: это как разговорный PHP и литературный. Вроде бы, да многие делают не по PSR, но в «обществе», так говорить — моветон.
Боюсь даже представить, как будет выглядеть конфиг с вашим MegaMenu на достаточно крупных проектах.
Что-то у вас с namespace не всё хорошо. В одном месте \app\core\components\MegaMenu, в другом \extpoint\megamenu\MegaMenu. На гитхабе у вас вроде всё с этим в порядке. По сабжу — для меня проблема кажется надуманной. Не вижу никаких проблем и сложностей в решении указанных задач для каждой отдельно взятой страницы.
На мой взгляд, если мы реализуем универсальный компонент, то было полезно опционально включить в компонент дополнительные поля, такие как
- метатег description
- метатеги Open Graph протокола
правильно я понимаю: при инициализации компонента он для своих целей инициализирует все 100 (ой, 1000) модулей моего проекта?
1. Это могут быть статичные методы модулей/контроллеров
2. Это все можно кешировать
Само мегаменю не решает эти задачи, решение возлагается на приложение.
2. Это все можно кешировать
Само мегаменю не решает эти задачи, решение возлагается на приложение.
1. Вы на чей-то чужой вопрос ответили?
2. Про существование кэша я в курсе. И есть понимание, что кэш при архитектурных проблемах — костыль, а в данном случае и проблему не решает, т.к. объекты остаются в памяти.
Я вижу, что модули, которые по умолчанию lazy и инициализируются только во время непосредственного обращения к их контроллерам, инициализируются вами принудительно, для извлечения информации из — внимание — метода coreMenu, который есть только на ваших проектах.
Это огромнейший фейл, ошибка в проектировании расширения и вообще сама по себе непонятная вещь — завязаться на какую-то специфичную для вас функциональность, подпортив производительность всем.
Решение: предусмотреть в компоненте интерфейс MenuProvider — для всех, а конкретно вам не завязываться на методы модулей, требующих их инициализации (статика как вы правильно подметили, но я бы в конфиг какой-то выносил — модуль не место для хранения конфигурационных данных).
2. Про существование кэша я в курсе. И есть понимание, что кэш при архитектурных проблемах — костыль, а в данном случае и проблему не решает, т.к. объекты остаются в памяти.
Я вижу, что модули, которые по умолчанию lazy и инициализируются только во время непосредственного обращения к их контроллерам, инициализируются вами принудительно, для извлечения информации из — внимание — метода coreMenu, который есть только на ваших проектах.
Это огромнейший фейл, ошибка в проектировании расширения и вообще сама по себе непонятная вещь — завязаться на какую-то специфичную для вас функциональность, подпортив производительность всем.
Решение: предусмотреть в компоненте интерфейс MenuProvider — для всех, а конкретно вам не завязываться на методы модулей, требующих их инициализации (статика как вы правильно подметили, но я бы в конфиг какой-то выносил — модуль не место для хранения конфигурационных данных).
1. На Ваш. Я имел ввиду, что если меню «хранится» в статичных методах, то не нужно инициализировать (создавать инстанс) всех модулей
В любом случае все решает кеш.
Реализацию модульности в boilerplate не навязываю, она не включается в MegaMenu. Это (принудительное создание экземпляра) действительно может повлиять на производительность, пересмотрю свое решение.
В любом случае все решает кеш.
Реализацию модульности в boilerplate не навязываю, она не включается в MegaMenu. Это (принудительное создание экземпляра) действительно может повлиять на производительность, пересмотрю свое решение.
1. «Если меню хранится», но я то писал про конкретный кусок реализации.
Это серьезно может повлиять. И опять же не надо придумывать способ хранения меню — предоставьте интферфейс и одну-две реализации. Не надо хардкодить, навязывая. Во многих проектах уже есть меню и не в том месте, где вы его захардкодите.
Это серьезно может повлиять. И опять же не надо придумывать способ хранения меню — предоставьте интферфейс и одну-две реализации. Не надо хардкодить, навязывая. Во многих проектах уже есть меню и не в том месте, где вы его захардкодите.
К примерно чему-то похожему пришел в своих меню и модулях.
Осветите пожалуйста NeatComet в одной из следующих статей.
Осветите пожалуйста NeatComet в одной из следующих статей.
Может быть я не понимаю ООП, но по моему использование правильных абстракций само по себе избавляет от ВСЕХ перечисленных Вами проблем без необходимости тащит внешнюю зависимость, да еще такую.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Уменьшаем боль в навигации приложения на Yii2