Pull to refresh

Comments 25

Посмотрел исходники и огорчен… где же PSR CodeStyle?
В чем именно отличия от PSR? В том, что "{" не переносится на новую строку в классах и методах?=)
И в расстановке пробелов. Но лично я не вижу ничего критического в данной ситуации.
UFO just landed and posted this here
+1 Судя по всему, автор уже привёл в соответствие с PSR.

Да, формально, PSR — всего лишь набор рекомендаций.
Но, де-факто это стандарт для open-source проектов, ибо альтернатив, достаточно распространённых чтобы быть достойными внимания, в современном PHP, лично я не вижу. Раньше, да у каждого более менее крупного фреймворка был свой стандарт.

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

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

PS: Не важно какое соглашение вы примите, важно что оно было принято©… Чистый / Совершенный Код (Мартин / Макконнелл)??
UFO just landed and posted this here
Пользуясь предложенной литературной метафорой, я бы определил PSR не как разновидность авторского стиля, а скорее как общепринятую для языка пунктуацию — как мы переносим слова, ставим запятые, большие буквы в начале предложения и т.п.

Ожидать и желать чтобы повсеместно был PSR, это что-то сродни Grammar-nazi. Но не вижу в этом ничего плохого.

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

У Брукса приводится мысль, что жесткие рамки стиля не мешают, а наоборот помогают настоящему мастеру.
UFO just landed and posted this here
Для ошибок на уровне синтаксиса языка, я бы привёл аналогию с грамматикой, орфографией — она однозначна как в естественных, так и в искусственных языках.

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

PSR при таком взгляде, это официальная пунктуация, e.g. рекомендованная «госпожой Вербицкой» (a.k.a FIG) сообщества PHP =)

PS: это как разговорный PHP и литературный. Вроде бы, да многие делают не по PSR, но в «обществе», так говорить — моветон.
Боюсь даже представить, как будет выглядеть конфиг с вашим MegaMenu на достаточно крупных проектах.
Оно прекрасно бьется на кусочки, указывая его в модулях и контроллерах. Пример есть тут — https://github.com/ExtPoint/project-boilerplate
Что-то у вас с namespace не всё хорошо. В одном месте \app\core\components\MegaMenu, в другом \extpoint\megamenu\MegaMenu. На гитхабе у вас вроде всё с этим в порядке. По сабжу — для меня проблема кажется надуманной. Не вижу никаких проблем и сложностей в решении указанных задач для каждой отдельно взятой страницы.
Спасибо за замечание, поправил.
Вы, видимо, просто не видели массив rules для UrlManager размером в 2 экрана. Есть некоторые удобства в данном решении, но я не буду его использовать для небольших проектов.
На мой взгляд, если мы реализуем универсальный компонент, то было полезно опционально включить в компонент дополнительные поля, такие как
  • метатег description
  • метатеги Open Graph протокола
Отличное предложение! Добавляю в TODO
правильно я понимаю: при инициализации компонента он для своих целей инициализирует все 100 (ой, 1000) модулей моего проекта?
1. Это могут быть статичные методы модулей/контроллеров
2. Это все можно кешировать
Само мегаменю не решает эти задачи, решение возлагается на приложение.
1. Вы на чей-то чужой вопрос ответили?
2. Про существование кэша я в курсе. И есть понимание, что кэш при архитектурных проблемах — костыль, а в данном случае и проблему не решает, т.к. объекты остаются в памяти.

Я вижу, что модули, которые по умолчанию lazy и инициализируются только во время непосредственного обращения к их контроллерам, инициализируются вами принудительно, для извлечения информации из — внимание — метода coreMenu, который есть только на ваших проектах.
Это огромнейший фейл, ошибка в проектировании расширения и вообще сама по себе непонятная вещь — завязаться на какую-то специфичную для вас функциональность, подпортив производительность всем.

Решение: предусмотреть в компоненте интерфейс MenuProvider — для всех, а конкретно вам не завязываться на методы модулей, требующих их инициализации (статика как вы правильно подметили, но я бы в конфиг какой-то выносил — модуль не место для хранения конфигурационных данных).
1. На Ваш. Я имел ввиду, что если меню «хранится» в статичных методах, то не нужно инициализировать (создавать инстанс) всех модулей
В любом случае все решает кеш.

Реализацию модульности в boilerplate не навязываю, она не включается в MegaMenu. Это (принудительное создание экземпляра) действительно может повлиять на производительность, пересмотрю свое решение.
1. «Если меню хранится», но я то писал про конкретный кусок реализации.

Это серьезно может повлиять. И опять же не надо придумывать способ хранения меню — предоставьте интферфейс и одну-две реализации. Не надо хардкодить, навязывая. Во многих проектах уже есть меню и не в том месте, где вы его захардкодите.
К примерно чему-то похожему пришел в своих меню и модулях.
Осветите пожалуйста NeatComet в одной из следующих статей.
NeatComet — библиотека моего коллеги, у него в todo стоит пункт «написать статью на хабр об этом»… Возможно и я напишу о ней в рамках Jii
Может быть я не понимаю ООП, но по моему использование правильных абстракций само по себе избавляет от ВСЕХ перечисленных Вами проблем без необходимости тащит внешнюю зависимость, да еще такую.
Т.е. вы предлагаете реализовывать подобие мегаменю в рамках приложения, а не отдельной библиотеки?) Как использование «правильных абстракций» избавляет от всех проблем, если архитектура Yii по-умолчанию диктует где что прописывать
Only those users with full accounts are able to leave comments. Log in, please.