Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 103
PSR-3 это логгер. Автозагрузка PSR-4.
Ну и про недопустимость статических классов и их тестирование это глупости. Если они не хранят состояние, то вполне себе нормальные и тестируемые
Ну и про недопустимость статических классов и их тестирование это глупости. Если они не хранят состояние, то вполне себе нормальные и тестируемые
> Ну и про недопустимость статических классов и их тестирование это глупости. Если они не хранят состояние, то вполне себе нормальные и тестируемые
Не соглашусь. Сами статические классы без состояния, конечно, тестируемые. Но как тестировать классы, которые их используют? Как расширять/переопределять статические классы?
Не соглашусь. Сами статические классы без состояния, конечно, тестируемые. Но как тестировать классы, которые их используют? Как расширять/переопределять статические классы?
Спасибо за развернутый комментарий, постараюсь дать развернутый ответ.
1)
PSR не является стандартом, это договоренность нескольких разработчиков популярных фреймворков и подобных решений (там так и написано).
Если посмотреть голосования за принятия разных PSR то можно найти голоса +1, 0 и даже -1 что значит не что иное как компромисс тех людей, что принимали участие в голосовании.
Мне не все их решения нравятся, поэтому то, какого стиля я придерживаюсь я описал на отдельной странице: github.com/nazar-pc/CleverStyle-CMS/wiki/Code-style
Какой стандарт принять не так важно, как следовать ему — я пытаюсь следовать одному стилю (указания на несоответствия приветствуются и будут оперативно исправляться), вот по совету ниже буду использовать CodeSniffer, так же имеется пример конфига стиля кода для PhpStorm на GitHub (на сколько он позволяет это настроить)
В конце концов я отправляю патчи в разные сторонние библиотеки, и всегда уважаю местный стиль написания, каким бы он не был.
2)
Никому ничего не должна, и на самом деле не PSR3, а PSR4 её описывает, прекрасно знаю о ней, если вы будете использовать composer — движок его подхватит и будет ценить, уважать, и даже любить PSR4 на сколько это возможно
3)
Есть поддержка composer, но ядру он не нужен. Компоненты при установке имеют внутренние зависимости, обрабатывают системные триггеры, добавляют/меняют таблицы БД (в какую БД ставить тоже определяется во время установки, поскольку их может быть несколько), с обновлением может быть ещё сложнее — миграции, перенастройка, и так далее.
В целом composer хорош для отдельных библиотек, но плагины в том же Wordpress вы через composer не поставите, это вам как небольшая аналогия.
4)
А я патчу, и не только PHP библиотеки, а и фронтенд, там больше изменений.
В целом — вот:
Пока патчи не были приняты в ядро и не вышли в релиз — с CleverStyle CMS поставлялись патченные версии, которые работали вместе.
Если вы предлагаете ставить ванильные версии которые будут иметь несовместимости — удачи вам, я так делать не буду (вот ещё разработчики Linux дистрибутивов постоянно патчат ядро, делают бекпорты, им расскажите ещё как нужно)
5)
А PHP тестируют с помощью тестов PHPT, таких же как у меня. И HHVM небезызвестный, тоже использует модифицированные PHPT тесты.
Можно им расказать, как проще и удобнее писать тесты, и как привлечь побольше людей на напиание.
6)
Какие же вы всё-таки категоричны, можно я не буду комментировать? И так целая статья получается вместо комментария.
7)
А движок это не запрещает, но и не навязывает, если там 20 строчек всего кода в файле и стилизируется через CSS (либо, ещё лучше, используются веб-компоненты, которые система любит и поощряет)
1)
PSR не является стандартом, это договоренность нескольких разработчиков популярных фреймворков и подобных решений (там так и написано).
Если посмотреть голосования за принятия разных PSR то можно найти голоса +1, 0 и даже -1 что значит не что иное как компромисс тех людей, что принимали участие в голосовании.
Мне не все их решения нравятся, поэтому то, какого стиля я придерживаюсь я описал на отдельной странице: github.com/nazar-pc/CleverStyle-CMS/wiki/Code-style
Какой стандарт принять не так важно, как следовать ему — я пытаюсь следовать одному стилю (указания на несоответствия приветствуются и будут оперативно исправляться), вот по совету ниже буду использовать CodeSniffer, так же имеется пример конфига стиля кода для PhpStorm на GitHub (на сколько он позволяет это настроить)
В конце концов я отправляю патчи в разные сторонние библиотеки, и всегда уважаю местный стиль написания, каким бы он не был.
2)
Никому ничего не должна, и на самом деле не PSR3, а PSR4 её описывает, прекрасно знаю о ней, если вы будете использовать composer — движок его подхватит и будет ценить, уважать, и даже любить PSR4 на сколько это возможно
3)
Есть поддержка composer, но ядру он не нужен. Компоненты при установке имеют внутренние зависимости, обрабатывают системные триггеры, добавляют/меняют таблицы БД (в какую БД ставить тоже определяется во время установки, поскольку их может быть несколько), с обновлением может быть ещё сложнее — миграции, перенастройка, и так далее.
В целом composer хорош для отдельных библиотек, но плагины в том же Wordpress вы через composer не поставите, это вам как небольшая аналогия.
4)
А я патчу, и не только PHP библиотеки, а и фронтенд, там больше изменений.
В целом — вот:
- патчил jQuery (были баги с использованием веб-компонентов, патч принят в ядро jQuery)
- Polymer Platform (WebComponents.js сегодня, там было несколько патчей, при желании найдете, приняты в ядро)
- fabric.js (тоже несовместимости с веб-компонентами, патч принят в ядро)
- UIkit (тоже веб-компоненты, патч принят в ядро)
- HHVM патчил, и ещё один патч висит, должны принять, хотя это и не касается движка напрямую, это позволяет ему устанавливаться и обновляться (в предыдущей статье есть комментарий по этому поводу)
- может ещё что-то забыл, вот сейчас патчится событие
$.ready()jQuery для всё тех же веб-компонентов
Пока патчи не были приняты в ядро и не вышли в релиз — с CleverStyle CMS поставлялись патченные версии, которые работали вместе.
Если вы предлагаете ставить ванильные версии которые будут иметь несовместимости — удачи вам, я так делать не буду (вот ещё разработчики Linux дистрибутивов постоянно патчат ядро, делают бекпорты, им расскажите ещё как нужно)
5)
А PHP тестируют с помощью тестов PHPT, таких же как у меня. И HHVM небезызвестный, тоже использует модифицированные PHPT тесты.
Можно им расказать, как проще и удобнее писать тесты, и как привлечь побольше людей на напиание.
6)
Какие же вы всё-таки категоричны, можно я не буду комментировать? И так целая статья получается вместо комментария.
7)
А движок это не запрещает, но и не навязывает, если там 20 строчек всего кода в файле и стилизируется через CSS (либо, ещё лучше, используются веб-компоненты, которые система любит и поощряет)
Код-стайл, простите, венгерскую нотацию напомнил. Ну и github.com/nazar-pc/CleverStyle-CMS/blob/master/components/modules/OAuth2/trigger.php — шедевр.
Табы длиные там. В текстовом редакторе вполне читаемо выглядит.
Именно по-этому в стандарте рекомендуется не использовать табы. Это не единичный случай — «текстовых редакторов» сотни, если не больше и везде будут табы разного размера. Так что наблюдаемая картина — думаю не самое худшее, что может произойти.
Так что наблюдаемая картина — думаю не самое худшее, что может произойти.
Скрытый текст
Ну например…
PhpStorm?
Project settings -> Code Style -> PHP -> Tabs and Indents
Project settings -> Code Style -> PHP -> Tabs and Indents
Та не важно, я просто показал на примере что может случиться с текстовыми редакторами. Это просто повезло что в шторме оно настраивается. А вдруг это будет какой-нибудь nano?
Просьба объяснить где я ошибаюсь в свой логике (а судя по минусам я сильно заблуждаюсь).
Пожалуйста.
Пожалуйста.
Думаю смысл в том, что в табах их минусы одновременно и плюсы, потому до сих пор нет единого мнения, что лучше.
Да в редакторе где не настраиваются табы может выглядеть странно, зато в нормальных редакторах вы можете настроить показывать именно так удобно и привычно, а не так как удобно автору, в пхпшторме для этого еще можно переформатировать под себя, только вот потом обратно придется вернуть (если получится) чтобы в контроле версии не напакостить
Да в редакторе где не настраиваются табы может выглядеть странно, зато в нормальных редакторах вы можете настроить показывать именно так удобно и привычно, а не так как удобно автору, в пхпшторме для этого еще можно переформатировать под себя, только вот потом обратно придется вернуть (если получится) чтобы в контроле версии не напакостить
Вернуть к начальному виду вообще не проблема.
Лично я сам прошёл через опыт табов и пришёл именно к пробелам, не потому что удобнее, а просто потому, что появился PSR.
Может своё фривольное изложение рекомендаций и удобнее (и не только сугубо, но и объективно), но тут вступает в силу привычка комьюнити, а в частности php-разработчика, как следствие — скорость чтения и анализа кода. А учитывая то, что ни PSR, ни PEAR, ни Zend, ни Symfony, ни Drupal стайлгайды не содержат рекомендаций к табам (т.е. большинство, по крайней мере из того, что я знаю), а наоборот только пробелы — думаю стоит наступить себе на горло и постараться переучиться, как я в своё время — это было тяжко, не спорю.
*Хочу заметить, что единственный выделяющийся из списка — это Wordpress, у него одного рекомендовано использовать табы (ссылка). Так что при разработке чего-либо именно к этой CMS — стоит использовать табы.
Может своё фривольное изложение рекомендаций и удобнее (и не только сугубо, но и объективно), но тут вступает в силу привычка комьюнити, а в частности php-разработчика, как следствие — скорость чтения и анализа кода. А учитывая то, что ни PSR, ни PEAR, ни Zend, ни Symfony, ни Drupal стайлгайды не содержат рекомендаций к табам (т.е. большинство, по крайней мере из того, что я знаю), а наоборот только пробелы — думаю стоит наступить себе на горло и постараться переучиться, как я в своё время — это было тяжко, не спорю.
*Хочу заметить, что единственный выделяющийся из списка — это Wordpress, у него одного рекомендовано использовать табы (ссылка). Так что при разработке чего-либо именно к этой CMS — стоит использовать табы.
PSR не являются стандартами. Размер табов настраивается в большинстве современных редакторов. Табы vs пробелы старая избитая тема. Тут на хабре тоже уже не раз это обсуждалось.
Имхо, большинство доводов в этих спорах не существенны. Использование табов или пробелов в большинстве случаев зависит только от вкусов и привычек программиста. Ну и от стандартов, которым он вынужден следовать в конкретном проекте.
- Пора завязывать использовать символы табуляции в коде
- Пора завязывать использовать пробелы вместо табуляции в коде
- Примиряем любителей пробелов и табов
Имхо, большинство доводов в этих спорах не существенны. Использование табов или пробелов в большинстве случаев зависит только от вкусов и привычек программиста. Ну и от стандартов, которым он вынужден следовать в конкретном проекте.
Да я про неймспейс s в пятом уровне вложенности и очень внятном триггере, в общем-то.
Да тут проблема, как мне кажется даже не в самом codestyle… Почему многие php программисты так любят елочки из условных операторов, цоклов и прочего?
Многие php-программисты просто не читали уважаемого Макконнела и даже не задумывались о том, что код можно написать ещё удобнее и читаемее ;)
А программисты не любят (хотя в детстве считать скобочки в ЛИСПе было удовольствием, да). Для этого за многие годы придумали способы управления сложностью функций. Кстати, именно так и появилось ООП.
В целом composer хорош для отдельных библиотек, но плагины в том же Wordpress вы через composer не поставите, это вам как небольшая аналогия.
Просто оставлю это здесь wpackagist.org
Имхо, PSR проще использовать, чем пытаться плыть против течения ради принципа, собственно тот же Yii ещё сопротивляется, но в результате — его стандарт совместим с PSR-2
Забавно читать вот такие комментарии по чьим-то работам. Мне примерно тоже самое отписали по моей статье, ну да не обо мне сейчас речь, я не такая важная персона. Ок, допустим, в этом проекте есть косяки. В любой человеческой работе есть косяки, мы все несовершенны, вы, OnYourLips, в том числе.
Смысл писать такие гневные «разоблачающие» посты человеку, который бесплатно выложил для всех результат своей работы? Он уже выше вас: он сделал что-то и передал это обществу. Цените таких людей, их не так много в нашем мире. И лучше помогите автору pull-запросами, исправляющими проблемы в проекте, если у вас действительно столько опыта и знаний, а умничать и пытаться зачем-то втоптать другого человека в грязь — это низко и подло, на мой взгляд.
Смысл писать такие гневные «разоблачающие» посты человеку, который бесплатно выложил для всех результат своей работы? Он уже выше вас: он сделал что-то и передал это обществу. Цените таких людей, их не так много в нашем мире. И лучше помогите автору pull-запросами, исправляющими проблемы в проекте, если у вас действительно столько опыта и знаний, а умничать и пытаться зачем-то втоптать другого человека в грязь — это низко и подло, на мой взгляд.
Комментарий из разряда «сначала добейся».
Т.е. суть хабра — это выпендриться друг перед другом крутой статьёй о каком-то проекте, в котором нет ни одной ошибки, и чтобы найти у другого какой-то косяк и потом опустить его по этой причине?) Что-то вроде общества гопарей или тюремщиков?
Я думал, суть хабра немного в другом, в более благом смысле, основа которого — помощь друг другу и стремление совместно решать проблемы этого мира. Я лично его и вижу таким.
Я думал, суть хабра немного в другом, в более благом смысле, основа которого — помощь друг другу и стремление совместно решать проблемы этого мира. Я лично его и вижу таким.
Человек и помог — пусть жестко, но объективно поделился своим опытом и указал на ошибки. Исправлять их за автора — это уже выходит за рамки помощи.
В каком смысле, «выходит за рамки помощи»? Все опенсорс проекты живут на такой основе: они пишутся совместно людьми. Весь Linux написан таким способом) Почему, интересно, Линусу Торвальдсу так не отписали, когда он только выложил первую версию своей ОС: мол, ок, хорошая попытка, дружище, но вот когда ты напишешь нам это, это и это — то мы, быть может, и будем это использовать. А пока нам не до тебя, помогать мы тебе не собираемся, т.к. «это выходит за рамки помощи». И вообще, ты — говно, извини, жёстко конечно, но пока ты — говно.
Таков был ответ цивилизованного сообщества людей?) По-моему, так пишут только нецивилизованные люди, которые даже совет не способны дать без упрёка и унижения.
Таков был ответ цивилизованного сообщества людей?) По-моему, так пишут только нецивилизованные люди, которые даже совет не способны дать без упрёка и унижения.
Опенсорс-проектов много, людей мало, а специалистов со свободным временем — и того меньше. Пулл-реквесты — это в 99% случаев не бескорыстное желание помочь, а попытка улучшить проект, которым ты пользуешься сам. Операционка Торвальдса не имела аналогов по лицензии распространения и потому оказалась востребована, в отличие от очередных велосипедов с нескучными обоями.
Наверное потому, что они увидели в Линухе какой-то потенциал в то время? Да и проектов подобных тогда было не так много.
А эти «совершенные» CMS запускаются по 10 штук в день.
А эти «совершенные» CMS запускаются по 10 штук в день.
Я с вами на спорю по этим вопросам, что вы написали, impwx, shoomyst. Я о другом: не оскорбляйте человека, если нашли в его работе ошибки. Мы все ошибаемся. Помогите ему подсказкой, советом, пулл-реквестом, и т.д., но зачем оскорблять его и унижать его работу? Вы от этого выше не становитесь, а человек может исправить свои ошибки.
А где вы оскорбления то углядели?
Там же весь коммент — один большой «вброс» практически) В стиле "у тебя вообще всё здесь неправильно, надо как я тебе сказал, и вообще, проект можно выкидывать в мусорку". Хотя в реальности, там почти все доводы являются спорными. Например, насчёт композера — это вообще дополнительная удобная модная фигня, которую можно, к тому же, к любому проекту самостоятельно прикрутить. Раньше без него спокойно жили.
Справедливости ради, Танненбаум именно так и ответил. Только грубее.
Естественно, что не все были согласны с Линусом тогда. Но факта это не меняет: те результаты во многих областях, которых достигли на текущий момент люди, реализовались благодаря взаимопомощи и поддержке друг другу, а не благодаря оскорблению и унижению чужих трудов.
И Э. Танненбаум, если я не путаю, писал всё-таки обоснованные, с его стороны, доводы про то, что ядро ОС не должно быть монолитным (хотя может я сейчас и что-то попутал, я не помню всё очень хорошо). И плюс он имел право написать подобные вещи, в силу того, кем он является и какой у него опыт.
Что касается нашей ситуации, то, как я заметил, у нас люди часто пишут посты только для того, чтобы набрать плюсы к своему комментарию, выпендриться перед другими и просто унизить автора статьи. При этом, сами они зачастую — вообще неизвестно кто и откуда. Трудно сопоставить подобные выходки с упомянутой вами реакцией профессора.
И Э. Танненбаум, если я не путаю, писал всё-таки обоснованные, с его стороны, доводы про то, что ядро ОС не должно быть монолитным (хотя может я сейчас и что-то попутал, я не помню всё очень хорошо). И плюс он имел право написать подобные вещи, в силу того, кем он является и какой у него опыт.
Что касается нашей ситуации, то, как я заметил, у нас люди часто пишут посты только для того, чтобы набрать плюсы к своему комментарию, выпендриться перед другими и просто унизить автора статьи. При этом, сами они зачастую — вообще неизвестно кто и откуда. Трудно сопоставить подобные выходки с упомянутой вами реакцией профессора.
Вот эта штука поможет вам следовать стандартам. github.com/squizlabs/PHP_CodeSniffer
Спасибо, буду использовать в ближайших сборках.
Можно не сильно заморачиваясь прикрутить scrutinizer-ci.com/ (будет что-то типа scrutinizer-ci.com/g/bluzphp/framework/)
Хороший ход с докер-контейнером. Просто и элегантно =)
Следующим уровенем по удобству будет пожалуй только one-click инсталяция в Bitnami
Следующим уровенем по удобству будет пожалуй только one-click инсталяция в Bitnami
Немного офтоп: у вас беда с отступами в коде и читать неудобно.
Можно решить проблему фильтрами git или пользоваться исключительно пробелами.
Можно решить проблему фильтрами git или пользоваться исключительно пробелами.
Исключительно пробелами не надо, отступы начала строки прекрасно отбиваются табами. А выравнивания внутри строки — только пробелы. Вообще на Хабре неоднократно обсуждалось, вот например habrahabr.ru/post/118208/
Я в основном это и имел в виду, и приведанный вами топик (как и другие на эту тему) мне прекрасно известен.
На github'e tab = 8 spaces, из-за чего код может быть растянут и изобретают такие трюки.
На github'e tab = 8 spaces, из-за чего код может быть растянут и изобретают такие трюки.
На github’e tab ≡ tab, 0x09, \t.
Это ваш браузер показывает вместо него 8 пробелов, гитхаб тут ни при чем.
Это ваш браузер показывает вместо него 8 пробелов, гитхаб тут ни при чем.
Поверьте, не только мой. Иначе бы не было экстеншенов для установки ширины таба на гитхабе для каждого браузера.
Возможно, я не верно выразился, но суть от этого не меняется.
Возможно, я не верно выразился, но суть от этого не меняется.
У таба на гитхабе (как и на всех без исключения остальных сайтах, документах, бумажках) длина — 1 (прописью: один) символ. Символ табуляции. ASCII код — 9.
Как его показывает браузер — никак не зависит от сайта, только от степени укуренности разработчиков браузера и от пользовательских стилей.
Как его показывает браузер — никак не зависит от сайта, только от степени укуренности разработчиков браузера и от пользовательских стилей.
Напишите это еще раз, если считаете что одного недостаточно.
Код на гитхабе, открытом в 4 браузерах, «плывет» от табов – это факт. Остальное вторично, о чем я и написал выше.
И к слову: я не писал, что гитхаб «виноват».
Код на гитхабе, открытом в 4 браузерах, «плывет» от табов – это факт. Остальное вторично, о чем я и написал выше.
И к слову: я не писал, что гитхаб «виноват».
Браузер его показывает так же, как любой текстовый редактор:
Из CSS гитхаба. Плагины для гитхаба можно написать проще теперь.
.tab-size-1{-moz-tab-size:1;-o-tab-size:1;tab-size:1}
.tab-size-2{-moz-tab-size:2;-o-tab-size:2;tab-size:2}
.tab-size-3{-moz-tab-size:3;-o-tab-size:3;tab-size:3}
.tab-size-4{-moz-tab-size:4;-o-tab-size:4;tab-size:4}
.tab-size-5{-moz-tab-size:5;-o-tab-size:5;tab-size:5}
.tab-size-6{-moz-tab-size:6;-o-tab-size:6;tab-size:6}
.tab-size-7{-moz-tab-size:7;-o-tab-size:7;tab-size:7}
.tab-size-8{-moz-tab-size:8;-o-tab-size:8;tab-size:8}
.tab-size-9{-moz-tab-size:9;-o-tab-size:9;tab-size:9}
.tab-size-10{-moz-tab-size:10;-o-tab-size:10;tab-size:10}
.tab-size-11{-moz-tab-size:11;-o-tab-size:11;tab-size:11}
.tab-size-12{-moz-tab-size:12;-o-tab-size:12;tab-size:12}
Из CSS гитхаба. Плагины для гитхаба можно написать проще теперь.
Я просил уже 2 раза в поддержки GitHub сделать табы настраиваемыми, без шансов пока, им нравится 8 пробелов на таб.
Если будете читать много исходников через GitHub — могу предложить то, что использую я, userstyle:
Это выставит на всех моих репозиториях табуляцию в 4 пробела, работает в Firefox, как в других честно говоря не знаю.
Если будете читать много исходников через GitHub — могу предложить то, что использую я, userstyle:
@-moz-document regexp("https?:\\/\\/github\.com\\/nazar-pc.*") {
* {
-moz-tab-size : 4;
}
}
Это выставит на всех моих репозиториях табуляцию в 4 пробела, работает в Firefox, как в других честно говоря не знаю.
Знакомы эти хаки. Мне удобнее пользоваться фильтрами, которые прозрачно транслируют табы<->пробелы при пушах/пулах.
И себе удобно, и на гитхабе код аккуратно выглядит, и у любителей править код в консоли проблем не возникает.
И себе удобно, и на гитхабе код аккуратно выглядит, и у любителей править код в консоли проблем не возникает.
А почему бы просто не использовать пробелы? Есть какие-то реальные аргументы против пробелов и за табы?
Прямо так и просили «распарсить все исходники и заменить в них символ табуляции на 4 пробела»? Там обычный ASCII[09], поэтому ваш стиль в браузере и работает (и это вовсе не хак).
Посмотрите assets-cdn.github.com/assets/github2-8b922a51411bd139fd6c83861e8c0a4568e7192869563d83ffadaca58d30b0b0.css
Найдите
Найдите
.tab-size-8, это подтверждение того, что виноват именно GitHub, он принудительно выставляет ширину табуляции в 8 пробелов.
Размер табов на github вполне можно настраивать через
?ts=2 query; ребятам нужно лишь это начать поддерживать например в .gitattributes.CleverStyle. Скромненько
Очень интересно, спасибо за статью)
Набор готовых модулей радует.
Как вариант, можно написать еще статью — пример создания какого-то мини-сайта с использованием вашей CMF, попутно описывая её особенности, разъясняя тонкости некоторых важных моментов. На мой взгляд, такая статья одновременно и описывает проект, и даёт возможность почерпнуть какие-то полезные идеи из кода, и добавляет информации для того, чтобы решить для себя — полезен этот проект вцелом, или бесполезен.
Набор готовых модулей радует.
Как вариант, можно написать еще статью — пример создания какого-то мини-сайта с использованием вашей CMF, попутно описывая её особенности, разъясняя тонкости некоторых важных моментов. На мой взгляд, такая статья одновременно и описывает проект, и даёт возможность почерпнуть какие-то полезные идеи из кода, и добавляет информации для того, чтобы решить для себя — полезен этот проект вцелом, или бесполезен.
Некоторое моё видение идеальной CMS:
1. Всё — дерево с правами доступа (простейшая аналогия — файловая система, вроде ext2/3/4, где всё файлы, но под ними устройства, файлы, ссылки и прочее), а каждая ветвь(лист?) дерева — самостоятельный модуль со структурированной формой входящий/исходящий данных. Допустим массив с обязательными полями вроде «status», «input_data», «output_data», «errors».
2. Всё превращается в статику (голый html файл и/или json/xml(простигосподи), размазанные по папкам), что не может превратиться — кеш в nosql (даже на 1-2 секунды).
3. Никакого WYSIWYG на подобии tinymce, заменить можно например markdown-ом.
4. Все данные должны быть доступны сторонним приложениям через api/json-файлы без лишних заморочек, но с разделением прав (см пункт 1).
5. Кажный чих пользователя не должен поднимать тонны всевозможного кода, лишнихсоедниений с БД и прочие излишества.
6. В идеале каждая часть 100% самостоятельна и может быть использована в отрыве от ядра CMS, но не возбраняется использовать сторонние библиотеки-зависимости. (спорный и сложнореализуемый пункт на самом деле)
7. Никаких оберток для стандартного функционала языка программирования (исключения наверно, когда программист признанный, а не самопровозглашенный гуру и без обертки совсем никак не обойтись).
8. Всё что можно сделать без лишних зависимостей и комбайнов, надо делать так.
9. Стараться не заменять без особой надобности стандартные элементы форм, кастомными «красивыми» наборами html-кода.
Почему:
1. Как то давно реализовал такое дерево для проекта, был в восторге от гибкости и добавления новых модулей.
2. Наверное не для кого ни секрет, что контент в основном поглащают и ничего быстрее «скачивания» текстового файла не может быть. Попутно можно весь этот набор файлов раскидать по серверам cdn, на которых ничего кроме например nginx нет.
3. Еще ни разу не видел чтобы не подготовленные (коих много) контент-менеджеры правильно сформировали структуру (заголовок не заголовок, а жирный большой текст, картинки под 100500Мпкс, отступы через и всё в таком духе).
4. Третьим лицам для вашего проекта легко писать приложения например для мобильных устройств. Вообще у меня сложилось мнение, что для веб проектов надо писать сперва API выдающее данные структурированным текстом (json/xml), а уже потом/попутно интерфейсы клиента и админку писать.
5. Видел несколько проектов на разных работах, где вывод куска кеша поднимал обработчики всего что можно на всякий случай (например работы с почтовыми отправлениями или API не связанного стороннего сервиса), а так же соединения со всеми источниками данных (та же mysql), в итоге медленно и жрет память в пустую ради того чтобы тут же умереть.
6. Например для написания нового модуля программисту не потребуется знать особенности той или иной CMS, достаточно знать в каком формате CMS отдает и принимает данные. Но тут и много сложностей и нюансов возникает с велосипедами и своими квадратными колесами.
7. Много раз видел как созданием sql запросов занимается фреймворк. С одной стороны это удобно и асбтрагируемся от СУБД, но при этом не всегда ясно что там эта обертка сделает с данными и как пользоваться особенностями той или иной СУБД (ради чего собственно она и выбирает, на сколько я понимаю).
8. Преувеличенный пример — ипользовать jQuery с большинством компонетов, чтобы один раз заменить нативный document.getElementById.
9. Вы пробовали этими красивыми выпадающими списочками, реагирующими на hover события на мобильных устройствах пользоваться?
Как то вот так =) Сам CMS не пишу и готовыми не пользуюсь, а занимаюсь сборкой и копипастом того что было когда то сделано в то что именно хочу сам или клиент — долго (дорого) и муторно но конечный результат предсказуем и радует.
Еще можно было бы поговорить о юзабилити для конечного пользователя (как клиента, так и админа движка), но я от этого далек и моё видение удобства наверняка отличается от видения любого другого человека и скорее всего это не выгодно.
1. Всё — дерево с правами доступа (простейшая аналогия — файловая система, вроде ext2/3/4, где всё файлы, но под ними устройства, файлы, ссылки и прочее), а каждая ветвь(лист?) дерева — самостоятельный модуль со структурированной формой входящий/исходящий данных. Допустим массив с обязательными полями вроде «status», «input_data», «output_data», «errors».
2. Всё превращается в статику (голый html файл и/или json/xml(простигосподи), размазанные по папкам), что не может превратиться — кеш в nosql (даже на 1-2 секунды).
3. Никакого WYSIWYG на подобии tinymce, заменить можно например markdown-ом.
4. Все данные должны быть доступны сторонним приложениям через api/json-файлы без лишних заморочек, но с разделением прав (см пункт 1).
5. Кажный чих пользователя не должен поднимать тонны всевозможного кода, лишнихсоедниений с БД и прочие излишества.
6. В идеале каждая часть 100% самостоятельна и может быть использована в отрыве от ядра CMS, но не возбраняется использовать сторонние библиотеки-зависимости. (спорный и сложнореализуемый пункт на самом деле)
7. Никаких оберток для стандартного функционала языка программирования (исключения наверно, когда программист признанный, а не самопровозглашенный гуру и без обертки совсем никак не обойтись).
8. Всё что можно сделать без лишних зависимостей и комбайнов, надо делать так.
9. Стараться не заменять без особой надобности стандартные элементы форм, кастомными «красивыми» наборами html-кода.
Почему:
1. Как то давно реализовал такое дерево для проекта, был в восторге от гибкости и добавления новых модулей.
2. Наверное не для кого ни секрет, что контент в основном поглащают и ничего быстрее «скачивания» текстового файла не может быть. Попутно можно весь этот набор файлов раскидать по серверам cdn, на которых ничего кроме например nginx нет.
3. Еще ни разу не видел чтобы не подготовленные (коих много) контент-менеджеры правильно сформировали структуру (заголовок не заголовок, а жирный большой текст, картинки под 100500Мпкс, отступы через и всё в таком духе).
4. Третьим лицам для вашего проекта легко писать приложения например для мобильных устройств. Вообще у меня сложилось мнение, что для веб проектов надо писать сперва API выдающее данные структурированным текстом (json/xml), а уже потом/попутно интерфейсы клиента и админку писать.
5. Видел несколько проектов на разных работах, где вывод куска кеша поднимал обработчики всего что можно на всякий случай (например работы с почтовыми отправлениями или API не связанного стороннего сервиса), а так же соединения со всеми источниками данных (та же mysql), в итоге медленно и жрет память в пустую ради того чтобы тут же умереть.
6. Например для написания нового модуля программисту не потребуется знать особенности той или иной CMS, достаточно знать в каком формате CMS отдает и принимает данные. Но тут и много сложностей и нюансов возникает с велосипедами и своими квадратными колесами.
7. Много раз видел как созданием sql запросов занимается фреймворк. С одной стороны это удобно и асбтрагируемся от СУБД, но при этом не всегда ясно что там эта обертка сделает с данными и как пользоваться особенностями той или иной СУБД (ради чего собственно она и выбирает, на сколько я понимаю).
8. Преувеличенный пример — ипользовать jQuery с большинством компонетов, чтобы один раз заменить нативный document.getElementById.
9. Вы пробовали этими красивыми выпадающими списочками, реагирующими на hover события на мобильных устройствах пользоваться?
Как то вот так =) Сам CMS не пишу и готовыми не пользуюсь, а занимаюсь сборкой и копипастом того что было когда то сделано в то что именно хочу сам или клиент — долго (дорого) и муторно но конечный результат предсказуем и радует.
Еще можно было бы поговорить о юзабилити для конечного пользователя (как клиента, так и админа движка), но я от этого далек и моё видение удобства наверняка отличается от видения любого другого человека и скорее всего это не выгодно.
Но если интересно
Но если интересно, я бы предпочел единый настраиваемый интерфейс для всех сайтов, так как лично я прихожу на сайт за информацией, а не полюбоваться на то какие загогулины еще выдумал дизайнер. А в дальнейшем вообще соединение всего этого, т.е. что-то вроде очень продвинутого RSS агрегатора (кто ипользовать palm/hp webos с synergy или месенджер на nokia ~n900 быстро моймет мою идею).
Я как-то страдал над подобными требованиями, в результате получилась микро-cms, я даже на ней пару сайтов только сделал, и потом почила она в архиве — anton.shevchuk.name/php/icms-cms-like-no-other/
CMS под ваши требования куча, если брать на PHP то могу порекомендовать Phrozn или Piecrust. Но это все хорошо когда контент менеджер вы сам или любой другой подкованный человек. К сожалению если сайтом занимаются маркетологи, им нужен конструктор. Либо все их каждодневные правки придется делать вам.
Спасибо за рекомендации. По описанию выглядит интересно, но надо попробовать, чтобы знать наверняка. (Да и я уже себе написал то что хотел для личных нужд, правда вместо статики выдается кеш из redis и есть mysql позади, но для хомяка сойдет).
Markdown не так уж сложен для формирования контента (по сути вместо окна с tinymce будет стандарное поле textarea), иерархию с модулями так же не сложно задать заранее (и заблокировать, чтобы не поудаляли лишнее).
Конечному контент-менеджеру вообще лучше дать как можно меньше возможностей портить, вы видели все эти сайты на wix и ucoz? Безбутылслез не взгляшень, а обилие виджетов заставляет иногда напрягаться комп не уже чем от современной игры.
Основная проблема скорее всего будет в том что у такого проекта мало возможностей на старе, а без них им не будут пользоватеться, а если не будут пользоваться, то и смысла развивать особо нет. Да и скорость работы любой CMS для среднестатистического сайта, при нынешних мощностях и ценах не критична, чтобы заморачиваться с кешем или статикой. А для крупного уникального проекта (или вырасшего из стандарной CMS) всеравно с нуля писать придется и оптимизировать под инфраструктуру.
В общем хотелка — это одно, а реальность — совсем другое.
И мне кажется CMS и вообще сайты понемного отмирают, потенциальные клиенты расползлись по социальным сетям, где можно впаривать продукцию целенаправленно, а не когда юзер найдет сайт через поисковик. Я думаю что будущее за унифицированным хранением контента и интерфейсе/агреггаторе для этой цели. По аналогии — можно искать и покупать книги с разным размером шрифта, а можно в централизованном магазине купить цифровую версию (данные), а в читалке (интерфейс/агреггатор) подстроить оформление под себя и с удовольствием потреблять контент в удобной форме (я думаю люди с ограниченными возможностями то же не откажутся от такого варианта).
Markdown не так уж сложен для формирования контента (по сути вместо окна с tinymce будет стандарное поле textarea), иерархию с модулями так же не сложно задать заранее (и заблокировать, чтобы не поудаляли лишнее).
Конечному контент-менеджеру вообще лучше дать как можно меньше возможностей портить, вы видели все эти сайты на wix и ucoz? Без
Основная проблема скорее всего будет в том что у такого проекта мало возможностей на старе, а без них им не будут пользоватеться, а если не будут пользоваться, то и смысла развивать особо нет. Да и скорость работы любой CMS для среднестатистического сайта, при нынешних мощностях и ценах не критична, чтобы заморачиваться с кешем или статикой. А для крупного уникального проекта (или вырасшего из стандарной CMS) всеравно с нуля писать придется и оптимизировать под инфраструктуру.
В общем хотелка — это одно, а реальность — совсем другое.
И мне кажется CMS и вообще сайты понемного отмирают, потенциальные клиенты расползлись по социальным сетям, где можно впаривать продукцию целенаправленно, а не когда юзер найдет сайт через поисковик. Я думаю что будущее за унифицированным хранением контента и интерфейсе/агреггаторе для этой цели. По аналогии — можно искать и покупать книги с разным размером шрифта, а можно в централизованном магазине купить цифровую версию (данные), а в читалке (интерфейс/агреггатор) подстроить оформление под себя и с удовольствием потреблять контент в удобной форме (я думаю люди с ограниченными возможностями то же не откажутся от такого варианта).
У каждого второго веб-разработчика, наверное, есть свой мега удобный велосипед. Я не против, более того, сам такой использую — CMS на основе Yii, правда времени очень не хватает, до версии 1.0 ещё очень далеко. Тем не менее, это не мешает применять его в своих работах, люди работают, не жалуются. По удобству использования, я думаю, уж точно не хуже популярных CMSок.
Вы все в 1 ветке разрабатываете или просто сейчас нет долгоиграющих фич на github?
Про composer и psr повторятся не буду, все выше было написано (проверку версии php и расширений тоже можно на откуп composer отдать.). События в вашей cms это Trigger или я их не нашел?
Для своих глобальный констант лучше префик завести.
Про composer и psr повторятся не буду, все выше было написано (проверку версии php и расширений тоже можно на откуп composer отдать.). События в вашей cms это Trigger или я их не нашел?
Для своих глобальный констант лучше префик завести.
Есть локальные ветки, но их мало пока, ибо фичи и правда реализовывались в течении нескольких коммитов, и не было смысла заводить новые ветки.
Да, события это Trigger.
От глобальных констант пытался избавиться, остались в основном константы с путями к системным директориям, наверное, стоит их вынести в отдельный namespace или правда префикс добавить, нужно подумать.
Да, события это Trigger.
От глобальных констант пытался избавиться, остались в основном константы с путями к системным директориям, наверное, стоит их вынести в отдельный namespace или правда префикс добавить, нужно подумать.
Проводим аналогию с CMS только.
Я ни разу не видел, чтобы какой-то программист, выпускающий, написанный на коленке, CMS или фреймворк, не считал её самой гибкой, удобной, быстрой и вообще идеальной. Иногда разработчики таких CMS настолько зарываются в её архитектуре и модулях, что даже не пробуют сделать на ней хоть один стоящий сайт, а если пробуют, то забывают о функциональных требованиях других людей, в результате чего получается (возможно) теоретически хорошая вещь, пока её используют в строго-пренастрого очерченной области. Если же разработчик стремится в сторону универсальности, получается нечто грустное и печальное вроде Drupal'a (при этом если потребуется расширение уже этой вещи, то оно пойдёт с огромным скрежетом).
Вопрос автору: вы смотрели в сторону Ruby On Rails? Простые конфиги, роутинг (одна строчка может формировать полный набор роутов к сущности: от view до destroy) и т. д… Кеширование автоматом через NGinx. Чем ваше творение лучше?
RoR — Это фрейм на рубях, пост про PHP. Так что если начали говорить о модных штуках — стоит упоминать Symfony или Laravel (последний прямо целыми кусками копия RoR).
Сила RoR в гемах и культуре разработки. Не достаточно просто скопировать фреймворк, нужно еще и философию оного перетащить. А это будет сложнее потому что PHP не Ruby.
В случае гемов — можно не беспокоиться за лару. А на счёт PHP не Ruby — согласен, у руби код намного лаконичнее. Ну как намного, надофига лаконичнее. С другой стороны его читать иногда сложнее, особенно когда ребята начинают использовать магию, вроде конкатенации строк через пробел.
Это не магия, это синтаксический сахар. Если вы пишите на руби — то проблемы нет. Мне вот приходится иногда в документацию лазить что бы понять что хотел изьявить разработчик, но не сказать что часто. Обычно код довольно логичен. А вот магия начинается когда открываешь для себя ObjectSpace. Вот это реально магия.
А по поводу «не беспокоиться за лару» — я и не беспокоюсь. Подавляющее количество решений под лару из тех что я видел жуткий говнокод.
А по поводу «не беспокоиться за лару» — я и не беспокоюсь. Подавляющее количество решений под лару из тех что я видел жуткий говнокод.
Язык не важен. Специально не начал здесь холивара по этому поводу. Тем не менее, если ощущается нехватка кислорода на PHP, думаю, через пару месяцев работы с RoR/Django не будет никакого сожаления, а только что-то вроде «Вау, это так просто, и не нужно городить велосипеды».
<deleted />
Asset Pipeline, Bundler, всякие Active Admin и прочие завлекающие и бесспорно удобные штуки — всё это есть и в Laravel сообществе. Просто язык другой — это да, не так элегантно получается как на Ruby\Python. С другой стороны у PHP есть свои конкурентные преимущества.
* А Symfony вполне себе справляется (более чем) с ролью Sinatra
* А Symfony вполне себе справляется (более чем) с ролью Sinatra
Нет, не смотрел в сторону RoR.
Конфиги здесь не сложные, часто они вообще не нужны.
А кэширование через NGinx — не совсем понимаю, что имеется ввиду, и какое отношение это может иметь здесь.
Для того чтобы сказать чем лучше нужно понимать RoR, а так как это ещё совсем другой язык — я фактически не в состоянии ответить на ваш вопрос.
Если будут конкретные примеры — смогу сопоставить аналогичное решение здесь, если много писать — можно в личку.
Конфиги здесь не сложные, часто они вообще не нужны.
А кэширование через NGinx — не совсем понимаю, что имеется ввиду, и какое отношение это может иметь здесь.
Для того чтобы сказать чем лучше нужно понимать RoR, а так как это ещё совсем другой язык — я фактически не в состоянии ответить на ваш вопрос.
Если будут конкретные примеры — смогу сопоставить аналогичное решение здесь, если много писать — можно в личку.
Мне кажется автор хочет исправить мир, а не изменить его.
Открыл видео-туториал из «Quick start [Backend] [Frontend] [dev] / Simplest block», т.к. и не нашёл простого и эффектного примера использования библиотеки. Забавно, что YouTube посоветовал посмотреть также youtu.be/fDvHLEbh-ao
Открыл видео-туториал из «Quick start [Backend] [Frontend] [dev] / Simplest block», т.к. и не нашёл простого и эффектного примера использования библиотеки. Забавно, что YouTube посоветовал посмотреть также youtu.be/fDvHLEbh-ao
Убрал вообще видео, они старые и страшненькие.
На счёт библиотеки не понял о чём вы.
На счёт библиотеки не понял о чём вы.
О том, что не увидел примера проблемы, которую решает Ваш продукт.
Решает проблему разработки сервисов с оригинальной функциональностью, такой, которая не вписывается в шаблонные плагины/бандлы и так далее.
Проблему можно решить как с помощью CMS, так и с помощью фреймворка, но мое решение позволяет сделать это с меньшими затратами времени и усилий. CMF не заточена под определённый вид сайтов, и не является набором разрозненных библиотек. Это монолитная универсальная основа, на которую легко навесить необходимый функционал.
Чаще всего встроенные возможности и компоненты можно использовать влоб, не настраивая, не прописывая сервисы в конфигурацию, просто дергаете в любом месте и получаете результат, например:
В любом месте в любое время. Просто вот так.
Произвольній запрос в БД (простой пример когда не предполагается несколько БД и подобных штук) с кэшированием результата:
Нет никаких фабрик, сервисов, не нужен плагин для IDE чтобы получать подсказки по всем методам и параметрам с комментариями что это такое, для чего, какие значения можно передавать.
В Symfony2, например, только для кэша вам нужно добавить зависимость в composer, обновить его, зарегистрировать бандл, прописать конфигурацию в конфигурационном файле, а если использовать для сессий и ещё чего-то — то ещё конфигурировать, а потом вызывать как свойство объекта контроллера, что скорее всего IDE без соответствующего плагина будет совершенно не понятно. А тут оно просто есть, и используется проще некуда, согласитесь.
Проблему можно решить как с помощью CMS, так и с помощью фреймворка, но мое решение позволяет сделать это с меньшими затратами времени и усилий. CMF не заточена под определённый вид сайтов, и не является набором разрозненных библиотек. Это монолитная универсальная основа, на которую легко навесить необходимый функционал.
Чаще всего встроенные возможности и компоненты можно использовать влоб, не настраивая, не прописывая сервисы в конфигурацию, просто дергаете в любом месте и получаете результат, например:
$Cache = \cs\Cache::instance();
$element = $Cache->element;
$Cache->element = 'new value';
unset($Cache->element);
В любом месте в любое время. Просто вот так.
Произвольній запрос в БД (простой пример когда не предполагается несколько БД и подобных штук) с кэшированием результата:
<?php
namespace cs;
$Cache = Cache::instance();
$User = User::instance();
$ids = $Cache->get("posts/$User->id", function () use ($User) { // If not in cache - call function
$db = DB::instance();
return $db->qfas( //Query, Fetch, Array, Single column
"SELECT `id`
FROM `[prefix]posts`
WHERE `user` = '%d'",
$User->id
);
);
foreach ($ids as $id) {
var_dump($id); // int(1), int(2), etc.
}
Нет никаких фабрик, сервисов, не нужен плагин для IDE чтобы получать подсказки по всем методам и параметрам с комментариями что это такое, для чего, какие значения можно передавать.
В Symfony2, например, только для кэша вам нужно добавить зависимость в composer, обновить его, зарегистрировать бандл, прописать конфигурацию в конфигурационном файле, а если использовать для сессий и ещё чего-то — то ещё конфигурировать, а потом вызывать как свойство объекта контроллера, что скорее всего IDE без соответствующего плагина будет совершенно не понятно. А тут оно просто есть, и используется проще некуда, согласитесь.
Нет никаких фабрик, сервисов
Вы считаете что это плюс? Что вы предлагаете использовать вместо? Статические классы?
$Cache = Cache::instance();
$User = User::instance();
Это ж ужас… Как это тестами покрывать, мокать инстансы которые передаются в Cache::instance? Можете написать простенький тестик под класс? Или предлагаете вообще отказаться от юнит тестов и полагаться только на интеграционные/функциональные?
Отлаженная система в тестах не нуждается, же.
Скрытый текст
То есть, это, конечно, проблемы тестов, которые не умеют в static::instance, да и, к тому же, не покрывают значительной части возможных ситуаций.
Вы правы, отлаженная система не нуждается в тестах… до первых правок… А потом случаются регрессии, часы отладки, тестировать надо, менеджеры ругаются, клиент расстроен потому что он всего-то хотел «кнопочку вставить а они сломали все, как это так! ЗА что я плачу?»
Вот и поговорили…
То есть, это, конечно, проблемы тестов
Вот и поговорили…
С точки зрения использования — несомненно, с точки зрения тестирования — скорее нет чем да.
Сейчас тестов мало (тестируется сборка системы в нескольких конфигурациях, устрановка, общаяя работоспособность после установки, авторизация, несколько системных объектов) и они интеграционные.
В целом вместо фабрик, DI и прочего есть трейт
Если переопределить трейт и этот метод (так как используется автозагрузка — просто подключить трейт перед первым использованием) — легко можно добавить возможность мокать любые объекты перед вызовом с помощью Setter injection, или вообще соорудить что угодно, так как единая точка, сквозь которую проходят все вызовы есть, метод
Другое дело что мне это показалось слишком сложным, интеграционные тесты гораздо проще в написании и чтении. Конечно, иногда вместо одного класса иногда поднимается несколько, иногда почти вся система заводится. Но при количестве тестов меньше миллиона это не имеет значения, так как скорость работы всё равно достаточно большая.
Сейчас тестов мало (тестируется сборка системы в нескольких конфигурациях, устрановка, общаяя работоспособность после установки, авторизация, несколько системных объектов) и они интеграционные.
В целом вместо фабрик, DI и прочего есть трейт
Singleton, и его метод instance.Если переопределить трейт и этот метод (так как используется автозагрузка — просто подключить трейт перед первым использованием) — легко можно добавить возможность мокать любые объекты перед вызовом с помощью Setter injection, или вообще соорудить что угодно, так как единая точка, сквозь которую проходят все вызовы есть, метод
Singleton::instance(), и у вас есть возможность управлять тем, что он вернет в результате вызова, а с помощью самого Singleton у вас есть возможность при необходимости добавить методы во все классы его использующие.Другое дело что мне это показалось слишком сложным, интеграционные тесты гораздо проще в написании и чтении. Конечно, иногда вместо одного класса иногда поднимается несколько, иногда почти вся система заводится. Но при количестве тестов меньше миллиона это не имеет значения, так как скорость работы всё равно достаточно большая.
Вот пример, я определил альтернативный класс
Core в пространстве имен cs\custom, по скольку я знаю, что из внешнего мира будет использоваться только этот класс, то есть тест получился почти Unit (он затрагивает не только cs/Cache, но и конкретную реализацию кэша APC) тест.Интеграционные тесты всеравно будут медленными. Суть тестов в том что бы получить фидбэк как можно раньше. Для этого даже ввели понятия такие как пирамида тестов.
И я правильно понимаю что кроме как с вашим каким-то странным фреймворком для тестирования ничего работать не будет или будет слишком сложно заставить работать?
То есть людям использующим TDD/BDD/DDD в своей работе путь закрыт?
Почему вы считаете что IoC контейнер усложит все? Зато можно было бы сделать систему удобнее для разработчика, вы же такой заголовок соорудили: «Собрать лучшее тра та та фреймворков и CMS». В целом же у вас получилась довольно посредственная коробочная CMS. Я бы даже сказал что Wordpress лучше внутри выглядит местами. По сути у вас все то же самое, компоненты доступны глобально, доступ к ним организован через глобальные сингелтоны… Ничего по поводу организации кода.
А теперь представьте как было бы удобно организовать разработку на базе CMS, которая позволяет за счет интерфейсов и аннотаций регламентировать поведение системы, а IoC и модуль конфигураций, нормальный раутер все бы это собирали вместе.
И я правильно понимаю что кроме как с вашим каким-то странным фреймворком для тестирования ничего работать не будет или будет слишком сложно заставить работать?
С точки зрения использования — несомненно, с точки зрения тестирования — скорее нет чем да.
То есть людям использующим TDD/BDD/DDD в своей работе путь закрыт?
Почему вы считаете что IoC контейнер усложит все? Зато можно было бы сделать систему удобнее для разработчика, вы же такой заголовок соорудили: «Собрать лучшее тра та та фреймворков и CMS». В целом же у вас получилась довольно посредственная коробочная CMS. Я бы даже сказал что Wordpress лучше внутри выглядит местами. По сути у вас все то же самое, компоненты доступны глобально, доступ к ним организован через глобальные сингелтоны… Ничего по поводу организации кода.
А теперь представьте как было бы удобно организовать разработку на базе CMS, которая позволяет за счет интерфейсов и аннотаций регламентировать поведение системы, а IoC и модуль конфигураций, нормальный раутер все бы это собирали вместе.
Интеграционные тесты будут медленнее, но не то чтобы совсем, к тому же большинство из них можно запускать параллельно.
Фреймворк для тестирования не странный, а вполне известный, используется при разработки самого языка PHP: github.com/php/php-src/blob/master/tests/basic/001.phpt
Зачем использовать для тестирования ядра второй фреймворк тестирования?
Тесты в конечный дистрибутив не включаются.
Люди, использующие TDD/BDD/DDD могут не использовать Singleton трейт, более того, у них в установке скорее всего не будет тестов ядра (они не нужны для работы), соответственно для разработки своих компонентов и написания тестов они могут использовать любой подход и любой фреймворк для тестирования. Нравится PHPT тесты — берите run-tests.php из репозитория движка, нет — используйте PHPUnit или что там вам нравится.
Движок тестируется таким образом — а каким образом будете тестировать вы — не навязывается. Вы можете в своих компонентах инжектить результат вызова
Потому что проще и понятнее уже, наверное, некуда. Я считаю, ядро должно быть предельно простым, и к этому стремлюсь.
Судя по описанию — похоже на Symfony CMF?
Если честно — меня очень смущает использование комментариев для чего-то большего чем, собственно, комментирования и PhpDoc. Возможно когда-то я прочитаю статью, которая разложит всё по полочкам, и изменит мое мнение, но пока считаю, комментарии не являются частью кода. Отсюда и неиспользование аннотаций.
Есть, к примеру,
Мне нравится как вы аргументируете, и я бы правда рад что-то из этого реализовать. Единственное условие — должно стать ещё проще, либо соразмерно по сложности, но иным способом. Но при этом и оверхеда быть не должно, работа с еми же аннотациями и рефлексией позволяет писать интересные решения, но это существенно тяжелее чем магические методы, особенно если использовать повсеместно.
Фреймворк для тестирования не странный, а вполне известный, используется при разработки самого языка PHP: github.com/php/php-src/blob/master/tests/basic/001.phpt
Зачем использовать для тестирования ядра второй фреймворк тестирования?
Тесты в конечный дистрибутив не включаются.
Люди, использующие TDD/BDD/DDD могут не использовать Singleton трейт, более того, у них в установке скорее всего не будет тестов ядра (они не нужны для работы), соответственно для разработки своих компонентов и написания тестов они могут использовать любой подход и любой фреймворк для тестирования. Нравится PHPT тесты — берите run-tests.php из репозитория движка, нет — используйте PHPUnit или что там вам нравится.
Движок тестируется таким образом — а каким образом будете тестировать вы — не навязывается. Вы можете в своих компонентах инжектить результат вызова
cs\Cache::instance(), а в тестах использовать Mockery. Не вижу проблемы здесь.Почему вы считаете что IoC контейнер усложит все?
Потому что проще и понятнее уже, наверное, некуда. Я считаю, ядро должно быть предельно простым, и к этому стремлюсь.
А теперь представьте как было бы удобно организовать разработку на базе CMS, которая позволяет за счет интерфейсов и аннотаций регламентировать поведение системы, а IoC и модуль конфигураций, нормальный раутер все бы это собирали вместе.
Судя по описанию — похоже на Symfony CMF?
Если честно — меня очень смущает использование комментариев для чего-то большего чем, собственно, комментирования и PhpDoc. Возможно когда-то я прочитаю статью, которая разложит всё по полочкам, и изменит мое мнение, но пока считаю, комментарии не являются частью кода. Отсюда и неиспользование аннотаций.
Есть, к примеру,
cs\Cache\_Abstract, который определяет интерфейс, необходимый классу для того, чтобы выступать в роли движка кэша, cs\Cache\APC его наследует и реализует абстрактные методы, а используете вы его не непосредственно, а через cs\Cache, который в зависимости от конфигурации использует тот или иной движок кэша под капотом. IoC тут по-моему совсем не нужен.Мне нравится как вы аргументируете, и я бы правда рад что-то из этого реализовать. Единственное условие — должно стать ещё проще, либо соразмерно по сложности, но иным способом. Но при этом и оверхеда быть не должно, работа с еми же аннотациями и рефлексией позволяет писать интересные решения, но это существенно тяжелее чем магические методы, особенно если использовать повсеместно.
Скрытый текст
Как-то знакомый показывал, какая замечательная Magento 2. Говорит, вот тут такое используется, вот тут такое (по-моему там были и части Zend, и Symfony), а настраивается это в прекрасных XML когфигах, а вот как оно работает…
Вот только в режиме отладки оно у него секунд 20-30 грузится, а в продакшн режиме с кэшированием — несколько секунд (состояние было близкое к ванильному).
Я не хочу видеть свою систему такой тормознутой, не хочу видеть километровые XML конфиги, шаблонные классы и прочие весьма характерные штуки. Скорость загрузки 2-4 мс это несоизмеримо быстрее, и позволяет писать сайты, в которых страница генерируется до 30 мс.
Вот только в режиме отладки оно у него секунд 20-30 грузится, а в продакшн режиме с кэшированием — несколько секунд (состояние было близкое к ванильному).
Я не хочу видеть свою систему такой тормознутой, не хочу видеть километровые XML конфиги, шаблонные классы и прочие весьма характерные штуки. Скорость загрузки 2-4 мс это несоизмеримо быстрее, и позволяет писать сайты, в которых страница генерируется до 30 мс.
Интеграционные тесты будут медленнее, но не то чтобы совсем
Да я как бы не спорю. Но все же они в десятки раз медленнее. Да и интеграционные тесты делать для вашей системы не просто. И боюсь что вообще никто не будет париться. Эдакий php старой школы, без тестов, архитектуры… wordpress с ООП.
Если честно — меня очень смущает использование комментариев...
Тут соглашусь. К сожалению аннотации как полноценную часть языка принимать не хотят… уже не помню почему отказались в свое время. В любом случае это годится только как один из вариантов конфигурации. И возможно какой-нибудь YML был бы лучше.
По поводу IoC — ядро должно быть простым, но IoC довольно простая штука. Ничего сложного. Зато не нужно следить за зависимостями, можно подменять реализации, автоматически регистрировать компоненты и т.д. То есть с точки зрения клиентского кода упрощается все. А это самое главное, это то что должна давать CMS. Тратить меньше сил на бойлерплейт и больше на бизнес логику. Ваше решение дает кастыль, который решает только часть проблемы но в неправильных руках (а таких большинство) дают возможность написать неподдерживаемый код.
Даже организация кода внутри ядра говорит уже о многом. Она слишком стихийна. Вы как разработчик ядра сделали все максимально удобным для себя.
Что до движка тестов — чем проще тесты тем больше от них толку. А писать простые тесты для вашего решения либо сложно, либо придется дополнительную прослойку писать. В любом случае 90% ваших пользователей не будут писать тесты. Скорее всего большинство будет просто тихонько говнокодить.
Что до магенты, у нее свои проблемы и она ориентируется на несколько другой сектор рынка. Это не быдло CMS которую можно поставить на шаред хостинг (хотя некоторые пытаются). Мне так же она не нравится, но она развивается, и насколько я помню они неплохо справляются. Мне кажется что вы восприняли статью о нелюбви к фреймворкам слишком буквально. И если вы 4 года убили на ЭТО, смею предположить что у вас небыло возможности оценить чем так хороши эти самые фреймворки. Хотя это вопрос личных предпочтений… но не спроста все же придумали SOLID и GRASP.
Зато не нужно следить за зависимостями, можно подменять реализации, автоматически регистрировать компоненты и т.д. То есть с точки зрения клиентского кода упрощается все.
Сейчас тоже не нужно следить за зависимостями.
Можно подменять реализации (справедливо для любого класса ядра или любого компонента, который использует Singleton, конечно же, при условии того что создается только один экземпляр нужного объекта):
<?php
# custom/Cache.php относительно корня сайта
namespace cs\custom;
class Cache extends \cs\Cache {
# Переопределяем что хотим и как хотим, если убрать наследование - вообще полная свобода
}
То есть такая функциональность работает на уровне Singleton::instance(), и вместо объекта оригинального класса можно вернуть что вам угодно. Единственное чего не хватает — на лету подменять один объект на другой, либо просто сбрасывать объект, чтобы несколько разных тестов можно было запускать в пределах одного скрипта, можно реализовать в виде Singleton::instance_reset(), и это не будет создавать накладных расходов когда не используется.
Я к тому, что при необходимости даже сейчас абсолютно всё можно реализовать с помощью подмены Singleton (скорее всего сделаю, чтобы он был более самодостаточным, и не нуждался в подмене), а использование IoC в данной ситуации не видится оправданным, так как дополнительной пользы не будет, будут только накладные расходы и необходимость конфигурирования того, что раньше в этом не нуждалось.
На счёт «автоматически регистрировать компоненты» не понял что имеется ввиду, по пространству имен понятно где должен лежать файл с классом, то есть они как бы уже зарегистрированы просто по определению.
По поводу тестов — получилось как-то так: github.com/nazar-pc/CleverStyle-CMS/blob/master/tests/Cache/APC_basic.phpt#L9
Или более сложный пример с методами: github.com/nazar-pc/CleverStyle-CMS/blob/master/tests%2FPage%2FMeta%2Fbasic_home.phpt#L9
Теперь вполне себе тестируемо, можно запускать несколько тестов с разными моками в рамках одного скрипта, применять блочное тестирование, и не нужно всё это тащить в продакшн.
Или более сложный пример с методами: github.com/nazar-pc/CleverStyle-CMS/blob/master/tests%2FPage%2FMeta%2Fbasic_home.phpt#L9
Теперь вполне себе тестируемо, можно запускать несколько тестов с разными моками в рамках одного скрипта, применять блочное тестирование, и не нужно всё это тащить в продакшн.
Чудно, только у вас нет моков. У вас стабы. А теперь смотрите… с точки зрения клиентского кода, с DI и прочими штуками, фреймворками для тестирования отдельными и без велосипедов:
Итого, у нас один класс для описания объектов, у нас есть возможность генерировать моки и подсовывать их в конструктор или сеттеры в let, никакого лишнего бойлерплейт кода, никаких захардкоженых стабов, тесты читабельны (а это важно), поддерживаемы и т.д. А ну и плюшки которые дает например тот же phpspec в контексте TDD — кодогенерация. Если вы написали тест, вы сразу его запускаете, даже если метода не существует — PhpSpec предложит вам его создать.
Все это не для того что бы что-то усложнять и меряться пиписьками. Все это банально экономит кучу времени. Большинство PHP-шников не пишет тестов только потому что с решениями подобными вашим они не эффективны и проще вручную все протестить. Некоторые сталкнувшись с тем что тесты писать долго и скучно просто забивают на них. И в итоге получают кучу регрессий в будущем.
Дискуссию не вижу смысла дальше продолжать. Удачи.
class MyRepositorSpec extends ObjectBehaviour
{
private $cacheMock;
// Cache это не класс а просто интерфейс.
// Вся магия превращающая его в мок на стороне Prophesy происходит.
function let(CleverStyle\Core\Cache $cache) {
$this->cacheMock = $cache;
}
function it_should_get_data_from_cache_if_it_is_available() {
$users = [['id' => 1, 'username' => 'nazarpc'], ['id' => 1, 'username' => 'fesor']];
// описываем какие методы должен дергать наш класс
// и записываем туда стабы
$this->cacheMock->has('users')->willReturn(true);
$this->cacheMock->get('users')->willReturn($users);
$this->findAll()->beLike($users);
}
function it_uses_db_only_if_no_data_in_cache_available()
{
$this->cacheMock->has('users')->willReturn(false);
}
}
Итого, у нас один класс для описания объектов, у нас есть возможность генерировать моки и подсовывать их в конструктор или сеттеры в let, никакого лишнего бойлерплейт кода, никаких захардкоженых стабов, тесты читабельны (а это важно), поддерживаемы и т.д. А ну и плюшки которые дает например тот же phpspec в контексте TDD — кодогенерация. Если вы написали тест, вы сразу его запускаете, даже если метода не существует — PhpSpec предложит вам его создать.
Все это не для того что бы что-то усложнять и меряться пиписьками. Все это банально экономит кучу времени. Большинство PHP-шников не пишет тестов только потому что с решениями подобными вашим они не эффективны и проще вручную все протестить. Некоторые сталкнувшись с тем что тесты писать долго и скучно просто забивают на них. И в итоге получают кучу регрессий в будущем.
Дискуссию не вижу смысла дальше продолжать. Удачи.
Комментариям нужен полноценный редактор?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cобрать лучшее из двух миров — фреймворков и CMS (часть 1)