Full-stack web developer, love Open Source
3,9
рейтинг
27 ноября 2014 в 09:48

Разработка → Cобрать лучшее из двух миров — фреймворков и CMS (часть 1)

Четыре года — это в IT уже долгострой. Именно столько, и даже чуть больше времени мне понадобилось чтобы довести CleverStyle CMS до версии 1.0, до состояния когда архитектура устаканилась, имеется достаточная функциональность и целостность системы как таковой, все найденные баги исправлены, и основные сценарии работают без проблем.

Получилось создать что-то среднее между фреймворком и, собственно, CMS, как раз то, что нужно для разработчика, и хочу поделиться этим с сообществом.

Уверен, многим не хватало именно такого решения, это подтверждается многочисленными вопросами на том же Тостере и долгими ветками комментариев под ними.

Обязательно нужно объяснить почему


Сложность, избыточность, гибкость, функциональность и скорость.



Я не нашел решения, которое имело бы удовлетворительный для меня баланс этих параметров (безопасность тоже, но это очевидно и подразумевается само собой изначально).
CleverStyle CMS — это не CMS в привычном смысле, это CMF, выше фреймворка по уровню архитектуры но ниже и гибче CMS.
В связи с таким позиционированием получилось очень удобное решение в первую очередь для разработки уникального функционала, так как есть большинство необходимых инструментов, за которыми не нужно далеко идти, не нужно настраивать, а можно сразу использовать и получать результат.

Отличия в сравнении с фреймворком:
Скрытый текст
Есть отличная статья в тему, которая немного проливает свет на мое к ним отношение Почему я ненавижу фреймворки

  • существенно меньше слоев абстракции
  • как следствие проще и прозрачнее структура
  • как следствие более высокая скорость работы и меньше потребление памяти (ядро отрабатывает за 2-4 мс и кушает около 1 МиБ памяти в пике, остальное зависит от разработчика конечного функционала)
  • не предполагает сборки из разнообразных компонентов — всё уже собрано и адекватно настроено
  • нет централизованного конфига маршрутов, каждый компонент хранит всё в себе
  • простота — благодаря более низкому уровню абстрактности кода порог входа значительно ниже
  • все части ядра подогнаны, при необходимости пропатчены, и гарантированно работают вместе, это не просто набор произвольных библиотек, а единое функциональное целое

В сравнении с CMS:

  • из коробки никакой специфической функциональности, только ядро и больше ничего
  • как следствие добавляется только необходимая функциональность
  • как следствие более высокая скорость работы и меньше потребление памяти
  • так же выше гибкость — настраивается и хакается буквально всё
  • практически не существует вида сайта, который нельзя сделать из-за архитектурных ограничений
  • поддержка вещей более характерных для фреймворков, например подхватывается composer, есть Restful API

Сложность, избыточность



Мне всегда не нравились файлы вида:

<?php
namespace Acme\DemoBundle;
use Symfony\Component\HttpKernel\Bundle\Bundle;
class AcmeDemoBundle extends Bundle
{
}

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

Как пример — вам практически никогда не нужно прописывать вручную подключение CSS/JS/HTML файлов на страницах — можно в простом JSON указать на каких страницах они нужны — система сделает это автоматически, а можно не указывать — тогда файлы будут подключены на всех страницах сайта (что иногда тоже вполне себе вариант).

Хотите Hello, world! — прямо так и пишете в index.html, ложите файл в папку модуля, включаете модуль в админке, он готов к работе. Не нужно кучи вложенных папок, шаблонных контроллеров и прочего — просто файл с контентом.

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

Настройки компонентов тоже хранятся в БД, и очищаются при удалении компонента, для управлением конфигурацией компонента есть предельно простой внутренний API — параметры задаются как свойства объекта.

Маршруты тоже работают максимально просто, в общем виде выглядит так: api|admin/Module_name/level_1/level_2, при этом всё кроме Module_name необязательно и используется только когда нужно.
На каждом уровне маршрута есть ответственный файл, который отрабатывает свой уровень, но если обработка нужна только на следующем уровне — на текущем обаботку можно пропустить.
Сами уровни описываются одно- или двумерным массивом в формате JSON:

{
	"level_1" : [
		"sublevel_1",
		"sublevel_2"
	]
}

При открытии страницы admin/Module_name/level_1/sublevel_1 отработают следующие файлы при наличии:

  • admin/index.php
  • admin/level_1.php
  • admin/level_1/sublevel_1.php

Так же из соображений простоты и удобства выбирались и сторонние компоненты, например:

  • PHPMailer — единственный файл, в котором есть всё для отправки почты, для поддержки SMTP нужен ещё один файл
  • PHPT тесты — запускаются из одного файла, писать и читать тесты просто (не зря их используют в разработке самого PHP, и, например, в модифицированном виде в HHVM), в отличии от монстра PHPUnit

Функциональность, скорость




Из коробки система понимает что бывает несколько БД, они могут быть разными, у них бывают зеркала, умеет случайным образом балансировать запросы между зеркалами (можно отправлять запросы на запись на мастер, а чтение на зеркала). Аналогично поддерживается несколько хранилищ для статики.

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

Есть пользователи группы пользователей, разрешения, которые можно назначать как группам, так и на отдельным пользователям, поддерживаются связи между пользователями (простая система контактов).

Есть интерфейс отправки почты, в том числе с вложениями и прочими нужными возможностями.

Повсеместное кэширование — в подавляющем большинстве запросов ядро даже не соединяется с БД, так как кэшируется всё, что имеет смысл кэшировать.

На фронтенде подключены jQuery, UIkit, Polymer (+ WebComponents.js), они настроены работать вместе (это не всегда тривиально, учитывая веб-компоненты).
Веб-компоненты используются наравне с обычным CSS/JS кодом, система понимает HTML импорты, можно использовать Paper Elements и любые сторонние готовые компоненты с легкостью.

Зависимости между компонентами (обязательные и не очень) автоматически влияют на порядок включения CSS/JS/HTML файлов на странице, так что у вас всегда будет предсказуемый и правильный порядок инициализации файлов.

CSS/JS/HTML файлы минифицируются, объединяются, жмутся с помощью gzip в отдельные файлы, которые подключаются всё так же с учётом зависимостей, система делает всё сама, в том числе выставляет заголовки для правильного кеширования файлов браузером и/или CDN.

Все создаваемые файлы и записи в БД контролируются, таким образом производительность является контролируемой и предсказуемой. Это дает комфортное ощущение контроля за состоянием сайта.

Также генерируются правильные мета-тэги чтобы объяснить поисковым системам на каких языках по какому адресу ещё доступна эта страница (в многоязычной конфигурации), генерируются Open Graph мета-тэги.

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

На самом деле есть не только ядро




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

  • Blogs — блог (одно и многопользовательский), организация частично почерпнута из хабрахабра
  • Comments — комментарии, интегрируется в другие компоненты
  • Disqus — аналогично Comments, но с использованием одноименного сервиса, интегрируется так же как Comments, можно на выбор брать либо один, либо другой
  • Cron — простой менеджер crontab (обертка над консольными командами)
  • Deferred tasks — позволяет отложить выполнение задачи, ускоряя ответ сервера, выполняя задачу в фоне
  • Feedback — простая обратная связь
  • Photo gallery — фотогаллерея
  • fotorama.js — jQuery плагин слайд-шоу для фото и не только, интегрируется с другими компонентами
  • Plupload — HTML5 загрузчик файлов, интегрируется в другие компоненты, работает как с кликом, так и с перетаскиванием файлов на объект (Drag & Drop)
  • TinyMCE — визуальный HTML редактор, интегрируется в другие компоненты
  • OAuth2 — сервер OAuth2, позволяет, например, подключать к сайту мобильные приложения
  • HybridAuth — вход на сайт через множество разнообразных социальных сетей и прочих сервисов
  • Content — создание простых элементов контента с возможностью редактировать на месте, интегрируется с другими компонентами, может использоваться сам по себе
  • Static pages — возможность создавать простые статические страницы

Кроме стандартной темы оформления, которая используется в основном только для админки есть ещё две, также сторонние портировать проще простого, ведь тема оформления — простой HTML файл, в который подставляется контент и некоторые другие данные (есть два примера портирования в GitHub с пошаговыми коммитами от исходного шаблона, до состояния когда он является темой оформления CleverStyle CMS).

Разное





Ядро CleverStyle CMS всего 2 МиБ и состоит примерно с 280 файлов (это уже включая все сторонние библиотеки), имеет всё необходимое для разработки подавляющего большинства всевозможных сайтов размером от визиток до масштабируемых на несколько серверов.

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

Архитектура спроектирована с нуля, несколько менялась со временем, учитывая опыт практического использования в продакшене, и устаканилась в таком виде, в котором есть сейчас.
В ядре используются как готовые сторонние библиотеки так и специально написанные, некоторые были написаны специально для CleverStyle CMS и потом отделились в самостоятельные проекты.

Код доступен на GitHub под MIT лицензией: https://github.com/nazar-pc/CleverStyle-CMS

Несмотря на то, что система должна рассматриваться скорее как монолит — многие части либо сразу, либо с небольшим усилием можно оторвать и использовать отдельно — например, минификация и объединение CSS/HTMLфайлов, реализация псевдо-файловой системы в кэше (по сути поддержка тэгов) для APC и Memcached, да и ещё много чего, код под MIT лицензией, можно использовать.

Есть wiki с описанием устройства и взаимодействия различных частей системы: https://github.com/nazar-pc/CleverStyle-CMS/wiki

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

Как попробовать




Демка с публично доступным сайтом плохо поддерживается — то пароль кто-то изменит, то настроит что-то, да и сломать с полным админским доступом при желании не сложно.
Благодаря тому, что последние версии поддерживают сборку и установку в режиме командной строки стало возможным приготовить образ для Docker с автоматически обновляемой и всегда последней git версией системы.
Запускается так:

docker run --rm -p 8888:8888 nazarpc/cleverstyle-cms

После этого можно открывать localhost:8888 и смотреть (логин admin, пароль 1111), все компоненты изначально отключены, но доступны в админке.
--rm удалит контейнер после остановки (остановить можно с помощью Ctrl+C).
Назар Мокринский @nazarpc
карма
30,0
рейтинг 3,9
Full-stack web developer, love Open Source
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (103)

  • +18
    Лучшее, говорите?
    github.com/nazar-pc/CleverStyle-CMS/blob/master/components/modules/Photo_gallery/edit_images.php

    Я бы от такого «лучшего» бежал, и волосы назад.
    • +12
      image
    • +19
      Автор темы попросил указать на ошибки.

      Ошибки, которые сразу видны без чтения кода. Недопустимы в принципе.
      1. Code Style. Код не может быть хорошим, есть он нечитаемый. Читаемость кода описана в PSR. Все PSR надо знать и выполнять. github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md
      2. Автозагрузка. Должна быть через composer и PSR-3.
      3. Composer сам по себе должен быть, и все зависимости должны ставиться через него? Нет зависимостей? Не может быть, велосипед пишете.

      Теперь ошибки, которые видно, если начать читать код.
      4. Недопустимо патчить чужие библиотеки, как сделано с PHPMailer.
      5. Для тестирования есть фреймворк phpunit и фреймворки, основанные на нем.
      6. Статические классы недопустимы. Они нормально не тестируются и приводят к сильной связанности кода. Исключения — фасады, как в Laravel.

      И самая главная ошибка:
      7. Нужно разделять бизнес-логику и отображение. Пример файла, который я привел — это полнейший ужас.

      Я уверен, что этот список можно продолжать и дальше, но смысла уже нет: даже несколько из этих ошибок в сумме достаточно серьезны, чтобы завершить проект.

      И поэтому пара советов напоследок. Не надо результаты самообучения выдавать за готовый продукт. И не надо учиться, делая велосипеды — это намного дольше, чем начать пользоваться самым лучшим кодом (фреймворки, библиотеки) чтобы понять, как и почему именно так они устроены.
      • +10
        PSR-3 это логгер. Автозагрузка PSR-4.
        Ну и про недопустимость статических классов и их тестирование это глупости. Если они не хранят состояние, то вполне себе нормальные и тестируемые
        • –1
          > Ну и про недопустимость статических классов и их тестирование это глупости. Если они не хранят состояние, то вполне себе нормальные и тестируемые

          Не соглашусь. Сами статические классы без состояния, конечно, тестируемые. Но как тестировать классы, которые их используют? Как расширять/переопределять статические классы?
      • +10
        Спасибо за развернутый комментарий, постараюсь дать развернутый ответ.

        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 (либо, ещё лучше, используются веб-компоненты, которые система любит и поощряет)
        • +1
          Код-стайл, простите, венгерскую нотацию напомнил. Ну и github.com/nazar-pc/CleverStyle-CMS/blob/master/components/modules/OAuth2/trigger.php — шедевр.
          • 0
            Табы длиные там. В текстовом редакторе вполне читаемо выглядит.
            • +2
              Именно по-этому в стандарте рекомендуется не использовать табы. Это не единичный случай — «текстовых редакторов» сотни, если не больше и везде будут табы разного размера. Так что наблюдаемая картина — думаю не самое худшее, что может произойти.
              • –1
                Так что наблюдаемая картина — думаю не самое худшее, что может произойти.
                Скрытый текст
                Ну например…
                • 0
                  PhpStorm?

                  Project settings -> Code Style -> PHP -> Tabs and Indents
                  • –4
                    Та не важно, я просто показал на примере что может случиться с текстовыми редакторами. Это просто повезло что в шторме оно настраивается. А вдруг это будет какой-нибудь nano?
                    • +1
                      Просьба объяснить где я ошибаюсь в свой логике (а судя по минусам я сильно заблуждаюсь).

                      Пожалуйста.
                      • 0
                        Думаю смысл в том, что в табах их минусы одновременно и плюсы, потому до сих пор нет единого мнения, что лучше.
                        Да в редакторе где не настраиваются табы может выглядеть странно, зато в нормальных редакторах вы можете настроить показывать именно так удобно и привычно, а не так как удобно автору, в пхпшторме для этого еще можно переформатировать под себя, только вот потом обратно придется вернуть (если получится) чтобы в контроле версии не напакостить
                        • 0
                          Вернуть к начальному виду вообще не проблема.
                        • +2
                          Лично я сам прошёл через опыт табов и пришёл именно к пробелам, не потому что удобнее, а просто потому, что появился PSR.

                          Может своё фривольное изложение рекомендаций и удобнее (и не только сугубо, но и объективно), но тут вступает в силу привычка комьюнити, а в частности php-разработчика, как следствие — скорость чтения и анализа кода. А учитывая то, что ни PSR, ни PEAR, ни Zend, ни Symfony, ни Drupal стайлгайды не содержат рекомендаций к табам (т.е. большинство, по крайней мере из того, что я знаю), а наоборот только пробелы — думаю стоит наступить себе на горло и постараться переучиться, как я в своё время — это было тяжко, не спорю.

                          *Хочу заметить, что единственный выделяющийся из списка — это Wordpress, у него одного рекомендовано использовать табы (ссылка). Так что при разработке чего-либо именно к этой CMS — стоит использовать табы.
              • +2
                PSR не являются стандартами. Размер табов настраивается в большинстве современных редакторов. Табы vs пробелы старая избитая тема. Тут на хабре тоже уже не раз это обсуждалось.


                Имхо, большинство доводов в этих спорах не существенны. Использование табов или пробелов в большинстве случаев зависит только от вкусов и привычек программиста. Ну и от стандартов, которым он вынужден следовать в конкретном проекте.
                • +1
                  + .editorconfig, который, кстати, надо гитхаб+битбакет обязать использовать для правил
            • +1
              Да я про неймспейс s в пятом уровне вложенности и очень внятном триггере, в общем-то.
          • 0
            Да тут проблема, как мне кажется даже не в самом codestyle… Почему многие php программисты так любят елочки из условных операторов, цоклов и прочего?
            • +1
              Многие php-программисты просто не читали уважаемого Макконнела и даже не задумывались о том, что код можно написать ещё удобнее и читаемее ;)
            • 0
              А программисты не любят (хотя в детстве считать скобочки в ЛИСПе было удовольствием, да). Для этого за многие годы придумали способы управления сложностью функций. Кстати, именно так и появилось ООП.
        • +3
          В целом composer хорош для отдельных библиотек, но плагины в том же Wordpress вы через composer не поставите, это вам как небольшая аналогия.

          Просто оставлю это здесь wpackagist.org
        • +3
          Имхо, PSR проще использовать, чем пытаться плыть против течения ради принципа, собственно тот же Yii ещё сопротивляется, но в результате — его стандарт совместим с PSR-2
      • –6
        Забавно читать вот такие комментарии по чьим-то работам. Мне примерно тоже самое отписали по моей статье, ну да не обо мне сейчас речь, я не такая важная персона. Ок, допустим, в этом проекте есть косяки. В любой человеческой работе есть косяки, мы все несовершенны, вы, OnYourLips, в том числе.

        Смысл писать такие гневные «разоблачающие» посты человеку, который бесплатно выложил для всех результат своей работы? Он уже выше вас: он сделал что-то и передал это обществу. Цените таких людей, их не так много в нашем мире. И лучше помогите автору pull-запросами, исправляющими проблемы в проекте, если у вас действительно столько опыта и знаний, а умничать и пытаться зачем-то втоптать другого человека в грязь — это низко и подло, на мой взгляд.
        • +6
          Комментарий из разряда «сначала добейся».
          • +1
            Т.е. суть хабра — это выпендриться друг перед другом крутой статьёй о каком-то проекте, в котором нет ни одной ошибки, и чтобы найти у другого какой-то косяк и потом опустить его по этой причине?) Что-то вроде общества гопарей или тюремщиков?

            Я думал, суть хабра немного в другом, в более благом смысле, основа которого — помощь друг другу и стремление совместно решать проблемы этого мира. Я лично его и вижу таким.
            • +7
              «опустить» и критика это разные вещи. Если вы не можете этого различить то печаль беда.
        • +5
          Смысл писать такое в том, чтоб помочь человеку.
          Если бы такое написали мне в свое время, я сэкономил бы огромное количество сил, времени и денег.

          > а умничать и пытаться зачем-то втоптать другого человека в грязь — это низко и подло, на мой взгляд.
          Вам тоже дам хороший совет. Не стоит искать и находить черную кошку в темной комнате, когда ее там нет.
          • 0
            Отписался ниже на эту тему другому человеку.
          • 0
            Смысл писать такое в том, чтоб помочь человеку.

            Когда-то мне сказали, что мой код — говно. Тогда я сделал шажок на новый уровень.

            Главное чтобы не было перехода на личности и оскорбления. Без этого такие вещи очень важны и нужны всем.
        • +2
          Человек и помог — пусть жестко, но объективно поделился своим опытом и указал на ошибки. Исправлять их за автора — это уже выходит за рамки помощи.
          • –2
            В каком смысле, «выходит за рамки помощи»? Все опенсорс проекты живут на такой основе: они пишутся совместно людьми. Весь Linux написан таким способом) Почему, интересно, Линусу Торвальдсу так не отписали, когда он только выложил первую версию своей ОС: мол, ок, хорошая попытка, дружище, но вот когда ты напишешь нам это, это и это — то мы, быть может, и будем это использовать. А пока нам не до тебя, помогать мы тебе не собираемся, т.к. «это выходит за рамки помощи». И вообще, ты — говно, извини, жёстко конечно, но пока ты — говно.

            Таков был ответ цивилизованного сообщества людей?) По-моему, так пишут только нецивилизованные люди, которые даже совет не способны дать без упрёка и унижения.
            • +4
              Опенсорс-проектов много, людей мало, а специалистов со свободным временем — и того меньше. Пулл-реквесты — это в 99% случаев не бескорыстное желание помочь, а попытка улучшить проект, которым ты пользуешься сам. Операционка Торвальдса не имела аналогов по лицензии распространения и потому оказалась востребована, в отличие от очередных велосипедов с нескучными обоями.
              • 0
                Про 99% спорно.
                • +4
                  А чего спорного? Если человек не пользуется проектом, то откуда он может узнать что в проекте можно улучшить/исправить?
                  • 0
                    Некоторые учавствуют в opensource проектах для того, чтобы просто набраться опыта, прокачать профиль на гитхабе и т.д. Конечно, одно другому не мешает.
            • 0
              Наверное потому, что они увидели в Линухе какой-то потенциал в то время? Да и проектов подобных тогда было не так много.
              А эти «совершенные» CMS запускаются по 10 штук в день.
            • –2
              Я с вами на спорю по этим вопросам, что вы написали, impwx, shoomyst. Я о другом: не оскорбляйте человека, если нашли в его работе ошибки. Мы все ошибаемся. Помогите ему подсказкой, советом, пулл-реквестом, и т.д., но зачем оскорблять его и унижать его работу? Вы от этого выше не становитесь, а человек может исправить свои ошибки.
              • +2
                А где вы оскорбления то углядели?
                • 0
                  Там же весь коммент — один большой «вброс» практически) В стиле "у тебя вообще всё здесь неправильно, надо как я тебе сказал, и вообще, проект можно выкидывать в мусорку". Хотя в реальности, там почти все доводы являются спорными. Например, насчёт композера — это вообще дополнительная удобная модная фигня, которую можно, к тому же, к любому проекту самостоятельно прикрутить. Раньше без него спокойно жили.
            • +5
              Справедливости ради, Танненбаум именно так и ответил. Только грубее.
              • +1
                Естественно, что не все были согласны с Линусом тогда. Но факта это не меняет: те результаты во многих областях, которых достигли на текущий момент люди, реализовались благодаря взаимопомощи и поддержке друг другу, а не благодаря оскорблению и унижению чужих трудов.

                И Э. Танненбаум, если я не путаю, писал всё-таки обоснованные, с его стороны, доводы про то, что ядро ОС не должно быть монолитным (хотя может я сейчас и что-то попутал, я не помню всё очень хорошо). И плюс он имел право написать подобные вещи, в силу того, кем он является и какой у него опыт.

                Что касается нашей ситуации, то, как я заметил, у нас люди часто пишут посты только для того, чтобы набрать плюсы к своему комментарию, выпендриться перед другими и просто унизить автора статьи. При этом, сами они зачастую — вообще неизвестно кто и откуда. Трудно сопоставить подобные выходки с упомянутой вами реакцией профессора.
                • 0
                  Я совершенно с вами согласен, я конкретно эту фразу прокомментировал:

                  > Почему, интересно, Линусу Торвальдсу так не отписали

  • +2
    Вот эта штука поможет вам следовать стандартам. github.com/squizlabs/PHP_CodeSniffer
    • 0
      Спасибо, буду использовать в ближайших сборках.
      • +2
        Можно не сильно заморачиваясь прикрутить scrutinizer-ci.com/ (будет что-то типа scrutinizer-ci.com/g/bluzphp/framework/)
        • 0
          И вам спасибо.
          Уже пробовал PhpMetrics для анализа некоторых метрик и рефакторинга в соответствующих местах, попробую и это, буду улучшать качество кода.
        • 0
          Ух ты какая штука заманчивая, спасибо огромное, не знал.
          Буквально за пару коммитов позволила улучшить код — всё грамотно и чётко пишет.
  • +2
    Хороший ход с докер-контейнером. Просто и элегантно =)
    Следующим уровенем по удобству будет пожалуй только one-click инсталяция в Bitnami
  • 0
    Немного офтоп: у вас беда с отступами в коде и читать неудобно.
    Можно решить проблему фильтрами git или пользоваться исключительно пробелами.
    • 0
      Исключительно пробелами не надо, отступы начала строки прекрасно отбиваются табами. А выравнивания внутри строки — только пробелы. Вообще на Хабре неоднократно обсуждалось, вот например habrahabr.ru/post/118208/
      • 0
        Я в основном это и имел в виду, и приведанный вами топик (как и другие на эту тему) мне прекрасно известен.
        На github'e tab = 8 spaces, из-за чего код может быть растянут и изобретают такие трюки.
        • 0
          На github’e tab ≡ tab, 0x09, \t.

          Это ваш браузер показывает вместо него 8 пробелов, гитхаб тут ни при чем.
          • 0
            Поверьте, не только мой. Иначе бы не было экстеншенов для установки ширины таба на гитхабе для каждого браузера.
            Возможно, я не верно выразился, но суть от этого не меняется.
            • 0
              У таба на гитхабе (как и на всех без исключения остальных сайтах, документах, бумажках) длина — 1 (прописью: один) символ. Символ табуляции. ASCII код — 9.

              Как его показывает браузер — никак не зависит от сайта, только от степени укуренности разработчиков браузера и от пользовательских стилей.
              • 0
                Напишите это еще раз, если считаете что одного недостаточно.
                Код на гитхабе, открытом в 4 браузерах, «плывет» от табов – это факт. Остальное вторично, о чем я и написал выше.

                И к слову: я не писал, что гитхаб «виноват».
              • +1
                Браузер его показывает так же, как любой текстовый редактор:

                .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 гитхаба. Плагины для гитхаба можно написать проще теперь.
    • 0
      Я просил уже 2 раза в поддержки GitHub сделать табы настраиваемыми, без шансов пока, им нравится 8 пробелов на таб.
      Если будете читать много исходников через GitHub — могу предложить то, что использую я, userstyle:

      @-moz-document regexp("https?:\\/\\/github\.com\\/nazar-pc.*") {
          * {
              -moz-tab-size : 4;
          }
      }
      

      Это выставит на всех моих репозиториях табуляцию в 4 пробела, работает в Firefox, как в других честно говоря не знаю.
      • 0
        Знакомы эти хаки. Мне удобнее пользоваться фильтрами, которые прозрачно транслируют табы<->пробелы при пушах/пулах.
        И себе удобно, и на гитхабе код аккуратно выглядит, и у любителей править код в консоли проблем не возникает.
      • 0
        А почему бы просто не использовать пробелы? Есть какие-то реальные аргументы против пробелов и за табы?
        • 0
          Думаю никаких реальных аргументов, кроме личных привычек/предпочтений в данном вопросе быть не может.
          Две противоположных статьи на хабре это подтверждают.
      • 0
        Прямо так и просили «распарсить все исходники и заменить в них символ табуляции на 4 пробела»? Там обычный ASCII[09], поэтому ваш стиль в браузере и работает (и это вовсе не хак).
        • 0
          Посмотрите assets-cdn.github.com/assets/github2-8b922a51411bd139fd6c83861e8c0a4568e7192869563d83ffadaca58d30b0b0.css
          Найдите .tab-size-8, это подтверждение того, что виноват именно GitHub, он принудительно выставляет ширину табуляции в 8 пробелов.
        • +1
          Размер табов на github вполне можно настраивать через ?ts=2 query; ребятам нужно лишь это начать поддерживать например в .gitattributes.
  • +6
    CleverStyle. Скромненько
  • 0
    Очень интересно, спасибо за статью)
    Набор готовых модулей радует.

    Как вариант, можно написать еще статью — пример создания какого-то мини-сайта с использованием вашей CMF, попутно описывая её особенности, разъясняя тонкости некоторых важных моментов. На мой взгляд, такая статья одновременно и описывает проект, и даёт возможность почерпнуть какие-то полезные идеи из кода, и добавляет информации для того, чтобы решить для себя — полезен этот проект вцелом, или бесполезен.
    • 0
      А я уже писал раньше, можете посмотреть мои посты, в целом статьи всё ещё актуальны, хотя есть и отличия, которые учитывают ту критику, которая есть под статьями. Если что есть wiki — там можно найти подробности.
  • +3
    Некоторое моё видение идеальной 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 быстро моймет мою идею).
    • +1
      Я как-то страдал над подобными требованиями, в результате получилась микро-cms, я даже на ней пару сайтов только сделал, и потом почила она в архиве — anton.shevchuk.name/php/icms-cms-like-no-other/
    • 0
      CMS под ваши требования куча, если брать на PHP то могу порекомендовать Phrozn или Piecrust. Но это все хорошо когда контент менеджер вы сам или любой другой подкованный человек. К сожалению если сайтом занимаются маркетологи, им нужен конструктор. Либо все их каждодневные правки придется делать вам.
      • 0
        Спасибо за рекомендации. По описанию выглядит интересно, но надо попробовать, чтобы знать наверняка. (Да и я уже себе написал то что хотел для личных нужд, правда вместо статики выдается кеш из redis и есть mysql позади, но для хомяка сойдет).
        Markdown не так уж сложен для формирования контента (по сути вместо окна с tinymce будет стандарное поле textarea), иерархию с модулями так же не сложно задать заранее (и заблокировать, чтобы не поудаляли лишнее).
        Конечному контент-менеджеру вообще лучше дать как можно меньше возможностей портить, вы видели все эти сайты на wix и ucoz? Без бутылслез не взгляшень, а обилие виджетов заставляет иногда напрягаться комп не уже чем от современной игры.
        Основная проблема скорее всего будет в том что у такого проекта мало возможностей на старе, а без них им не будут пользоватеться, а если не будут пользоваться, то и смысла развивать особо нет. Да и скорость работы любой CMS для среднестатистического сайта, при нынешних мощностях и ценах не критична, чтобы заморачиваться с кешем или статикой. А для крупного уникального проекта (или вырасшего из стандарной CMS) всеравно с нуля писать придется и оптимизировать под инфраструктуру.
        В общем хотелка — это одно, а реальность — совсем другое.
        И мне кажется CMS и вообще сайты понемного отмирают, потенциальные клиенты расползлись по социальным сетям, где можно впаривать продукцию целенаправленно, а не когда юзер найдет сайт через поисковик. Я думаю что будущее за унифицированным хранением контента и интерфейсе/агреггаторе для этой цели. По аналогии — можно искать и покупать книги с разным размером шрифта, а можно в централизованном магазине купить цифровую версию (данные), а в читалке (интерфейс/агреггатор) подстроить оформление под себя и с удовольствием потреблять контент в удобной форме (я думаю люди с ограниченными возможностями то же не откажутся от такого варианта).
  • +3
    У каждого второго веб-разработчика, наверное, есть свой мега удобный велосипед. Я не против, более того, сам такой использую — CMS на основе Yii, правда времени очень не хватает, до версии 1.0 ещё очень далеко. Тем не менее, это не мешает применять его в своих работах, люди работают, не жалуются. По удобству использования, я думаю, уж точно не хуже популярных CMSок.
  • +1
    Вы все в 1 ветке разрабатываете или просто сейчас нет долгоиграющих фич на github?
    Про composer и psr повторятся не буду, все выше было написано (проверку версии php и расширений тоже можно на откуп composer отдать.). События в вашей cms это Trigger или я их не нашел?

    Для своих глобальный констант лучше префик завести.
    • 0
      Есть локальные ветки, но их мало пока, ибо фичи и правда реализовывались в течении нескольких коммитов, и не было смысла заводить новые ветки.
      Да, события это Trigger.
      От глобальных констант пытался избавиться, остались в основном константы с путями к системным директориям, наверное, стоит их вынести в отдельный namespace или правда префикс добавить, нужно подумать.
      • 0
        Есть локальные ветки, но их мало пока

        Я надеюсь, вы их бекапите хотя бы. А то вдруг HDD сломается…
  • +4
    image
    Проводим аналогию с CMS только.

    Я ни разу не видел, чтобы какой-то программист, выпускающий, написанный на коленке, CMS или фреймворк, не считал её самой гибкой, удобной, быстрой и вообще идеальной. Иногда разработчики таких CMS настолько зарываются в её архитектуре и модулях, что даже не пробуют сделать на ней хоть один стоящий сайт, а если пробуют, то забывают о функциональных требованиях других людей, в результате чего получается (возможно) теоретически хорошая вещь, пока её используют в строго-пренастрого очерченной области. Если же разработчик стремится в сторону универсальности, получается нечто грустное и печальное вроде Drupal'a (при этом если потребуется расширение уже этой вещи, то оно пойдёт с огромным скрежетом).

    Вопрос автору: вы смотрели в сторону Ruby On Rails? Простые конфиги, роутинг (одна строчка может формировать полный набор роутов к сущности: от view до destroy) и т. д… Кеширование автоматом через NGinx. Чем ваше творение лучше?
    • +1
      RoR — Это фрейм на рубях, пост про PHP. Так что если начали говорить о модных штуках — стоит упоминать Symfony или Laravel (последний прямо целыми кусками копия RoR).
      • +1
        Сила RoR в гемах и культуре разработки. Не достаточно просто скопировать фреймворк, нужно еще и философию оного перетащить. А это будет сложнее потому что PHP не Ruby.
        • 0
          В случае гемов — можно не беспокоиться за лару. А на счёт PHP не Ruby — согласен, у руби код намного лаконичнее. Ну как намного, надофига лаконичнее. С другой стороны его читать иногда сложнее, особенно когда ребята начинают использовать магию, вроде конкатенации строк через пробел.
          • 0
            Это не магия, это синтаксический сахар. Если вы пишите на руби — то проблемы нет. Мне вот приходится иногда в документацию лазить что бы понять что хотел изьявить разработчик, но не сказать что часто. Обычно код довольно логичен. А вот магия начинается когда открываешь для себя ObjectSpace. Вот это реально магия.

            А по поводу «не беспокоиться за лару» — я и не беспокоюсь. Подавляющее количество решений под лару из тех что я видел жуткий говнокод.
      • 0
        Язык не важен. Специально не начал здесь холивара по этому поводу. Тем не менее, если ощущается нехватка кислорода на PHP, думаю, через пару месяцев работы с RoR/Django не будет никакого сожаления, а только что-то вроде «Вау, это так просто, и не нужно городить велосипеды».
        • 0
          <deleted />
        • 0
          Asset Pipeline, Bundler, всякие Active Admin и прочие завлекающие и бесспорно удобные штуки — всё это есть и в Laravel сообществе. Просто язык другой — это да, не так элегантно получается как на Ruby\Python. С другой стороны у PHP есть свои конкурентные преимущества.

          * А Symfony вполне себе справляется (более чем) с ролью Sinatra
    • 0
      Нет, не смотрел в сторону RoR.
      Конфиги здесь не сложные, часто они вообще не нужны.
      А кэширование через NGinx — не совсем понимаю, что имеется ввиду, и какое отношение это может иметь здесь.
      Для того чтобы сказать чем лучше нужно понимать RoR, а так как это ещё совсем другой язык — я фактически не в состоянии ответить на ваш вопрос.
      Если будут конкретные примеры — смогу сопоставить аналогичное решение здесь, если много писать — можно в личку.
  • 0
    Мне кажется автор хочет исправить мир, а не изменить его.
    Открыл видео-туториал из «Quick start [Backend] [Frontend] [dev] / Simplest block», т.к. и не нашёл простого и эффектного примера использования библиотеки. Забавно, что YouTube посоветовал посмотреть также youtu.be/fDvHLEbh-ao
    • 0
      Убрал вообще видео, они старые и страшненькие.
      На счёт библиотеки не понял о чём вы.
      • 0
        О том, что не увидел примера проблемы, которую решает Ваш продукт.
        • 0
          Решает проблему разработки сервисов с оригинальной функциональностью, такой, которая не вписывается в шаблонные плагины/бандлы и так далее.
          Проблему можно решить как с помощью 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 без соответствующего плагина будет совершенно не понятно. А тут оно просто есть, и используется проще некуда, согласитесь.
          • 0
            Нет никаких фабрик, сервисов

            Вы считаете что это плюс? Что вы предлагаете использовать вместо? Статические классы?

            $Cache = Cache::instance();
            $User = User::instance();
            


            Это ж ужас… Как это тестами покрывать, мокать инстансы которые передаются в Cache::instance? Можете написать простенький тестик под класс? Или предлагаете вообще отказаться от юнит тестов и полагаться только на интеграционные/функциональные?
            • 0
              Отлаженная система в тестах не нуждается, же.
              Скрытый текст
              То есть, это, конечно, проблемы тестов, которые не умеют в static::instance, да и, к тому же, не покрывают значительной части возможных ситуаций.
              • 0
                Вы правы, отлаженная система не нуждается в тестах… до первых правок… А потом случаются регрессии, часы отладки, тестировать надо, менеджеры ругаются, клиент расстроен потому что он всего-то хотел «кнопочку вставить а они сломали все, как это так! ЗА что я плачу?»

                То есть, это, конечно, проблемы тестов


                Вот и поговорили…
            • 0
              С точки зрения использования — несомненно, с точки зрения тестирования — скорее нет чем да.

              Сейчас тестов мало (тестируется сборка системы в нескольких конфигурациях, устрановка, общаяя работоспособность после установки, авторизация, несколько системных объектов) и они интеграционные.

              В целом вместо фабрик, DI и прочего есть трейт Singleton, и его метод instance.
              Если переопределить трейт и этот метод (так как используется автозагрузка — просто подключить трейт перед первым использованием) — легко можно добавить возможность мокать любые объекты перед вызовом с помощью Setter injection, или вообще соорудить что угодно, так как единая точка, сквозь которую проходят все вызовы есть, метод Singleton::instance(), и у вас есть возможность управлять тем, что он вернет в результате вызова, а с помощью самого Singleton у вас есть возможность при необходимости добавить методы во все классы его использующие.

              Другое дело что мне это показалось слишком сложным, интеграционные тесты гораздо проще в написании и чтении. Конечно, иногда вместо одного класса иногда поднимается несколько, иногда почти вся система заводится. Но при количестве тестов меньше миллиона это не имеет значения, так как скорость работы всё равно достаточно большая.
              • 0
                Вот пример, я определил альтернативный класс Core в пространстве имен cs\custom, по скольку я знаю, что из внешнего мира будет использоваться только этот класс, то есть тест получился почти Unit (он затрагивает не только cs/Cache, но и конкретную реализацию кэша APC) тест.
              • 0
                Интеграционные тесты всеравно будут медленными. Суть тестов в том что бы получить фидбэк как можно раньше. Для этого даже ввели понятия такие как пирамида тестов.

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

                С точки зрения использования — несомненно, с точки зрения тестирования — скорее нет чем да.

                То есть людям использующим TDD/BDD/DDD в своей работе путь закрыт?

                Почему вы считаете что IoC контейнер усложит все? Зато можно было бы сделать систему удобнее для разработчика, вы же такой заголовок соорудили: «Собрать лучшее тра та та фреймворков и CMS». В целом же у вас получилась довольно посредственная коробочная CMS. Я бы даже сказал что Wordpress лучше внутри выглядит местами. По сути у вас все то же самое, компоненты доступны глобально, доступ к ним организован через глобальные сингелтоны… Ничего по поводу организации кода.

                А теперь представьте как было бы удобно организовать разработку на базе CMS, которая позволяет за счет интерфейсов и аннотаций регламентировать поведение системы, а IoC и модуль конфигураций, нормальный раутер все бы это собирали вместе.
                • –1
                  Интеграционные тесты будут медленнее, но не то чтобы совсем, к тому же большинство из них можно запускать параллельно.

                  Фреймворк для тестирования не странный, а вполне известный, используется при разработки самого языка 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 мс.
                  • 0
                    Интеграционные тесты будут медленнее, но не то чтобы совсем

                    Да я как бы не спорю. Но все же они в десятки раз медленнее. Да и интеграционные тесты делать для вашей системы не просто. И боюсь что вообще никто не будет париться. Эдакий php старой школы, без тестов, архитектуры… wordpress с ООП.

                    Если честно — меня очень смущает использование комментариев...

                    Тут соглашусь. К сожалению аннотации как полноценную часть языка принимать не хотят… уже не помню почему отказались в свое время. В любом случае это годится только как один из вариантов конфигурации. И возможно какой-нибудь YML был бы лучше.

                    По поводу IoC — ядро должно быть простым, но IoC довольно простая штука. Ничего сложного. Зато не нужно следить за зависимостями, можно подменять реализации, автоматически регистрировать компоненты и т.д. То есть с точки зрения клиентского кода упрощается все. А это самое главное, это то что должна давать CMS. Тратить меньше сил на бойлерплейт и больше на бизнес логику. Ваше решение дает кастыль, который решает только часть проблемы но в неправильных руках (а таких большинство) дают возможность написать неподдерживаемый код.

                    Даже организация кода внутри ядра говорит уже о многом. Она слишком стихийна. Вы как разработчик ядра сделали все максимально удобным для себя.

                    Что до движка тестов — чем проще тесты тем больше от них толку. А писать простые тесты для вашего решения либо сложно, либо придется дополнительную прослойку писать. В любом случае 90% ваших пользователей не будут писать тесты. Скорее всего большинство будет просто тихонько говнокодить.

                    Что до магенты, у нее свои проблемы и она ориентируется на несколько другой сектор рынка. Это не быдло CMS которую можно поставить на шаред хостинг (хотя некоторые пытаются). Мне так же она не нравится, но она развивается, и насколько я помню они неплохо справляются. Мне кажется что вы восприняли статью о нелюбви к фреймворкам слишком буквально. И если вы 4 года убили на ЭТО, смею предположить что у вас небыло возможности оценить чем так хороши эти самые фреймворки. Хотя это вопрос личных предпочтений… но не спроста все же придумали SOLID и GRASP.
                    • 0
                      Зато не нужно следить за зависимостями, можно подменять реализации, автоматически регистрировать компоненты и т.д. То есть с точки зрения клиентского кода упрощается все.

                      Сейчас тоже не нужно следить за зависимостями.

                      Можно подменять реализации (справедливо для любого класса ядра или любого компонента, который использует Singleton, конечно же, при условии того что создается только один экземпляр нужного объекта):

                      <?php
                      # custom/Cache.php относительно корня сайта
                      namespace cs\custom;
                      class Cache extends \cs\Cache {
                          # Переопределяем что хотим и как хотим, если убрать наследование - вообще полная свобода
                      }
                      

                      То есть такая функциональность работает на уровне Singleton::instance(), и вместо объекта оригинального класса можно вернуть что вам угодно. Единственное чего не хватает — на лету подменять один объект на другой, либо просто сбрасывать объект, чтобы несколько разных тестов можно было запускать в пределах одного скрипта, можно реализовать в виде Singleton::instance_reset(), и это не будет создавать накладных расходов когда не используется.

                      Я к тому, что при необходимости даже сейчас абсолютно всё можно реализовать с помощью подмены Singleton (скорее всего сделаю, чтобы он был более самодостаточным, и не нуждался в подмене), а использование IoC в данной ситуации не видится оправданным, так как дополнительной пользы не будет, будут только накладные расходы и необходимость конфигурирования того, что раньше в этом не нуждалось.

                      На счёт «автоматически регистрировать компоненты» не понял что имеется ввиду, по пространству имен понятно где должен лежать файл с классом, то есть они как бы уже зарегистрированы просто по определению.
                    • 0
                      По поводу тестов — получилось как-то так: 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
                      Теперь вполне себе тестируемо, можно запускать несколько тестов с разными моками в рамках одного скрипта, применять блочное тестирование, и не нужно всё это тащить в продакшн.
                      • 0
                        Чудно, только у вас нет моков. У вас стабы. А теперь смотрите… с точки зрения клиентского кода, с DI и прочими штуками, фреймворками для тестирования отдельными и без велосипедов:

                        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-шников не пишет тестов только потому что с решениями подобными вашим они не эффективны и проще вручную все протестить. Некоторые сталкнувшись с тем что тесты писать долго и скучно просто забивают на них. И в итоге получают кучу регрессий в будущем.

                        Дискуссию не вижу смысла дальше продолжать. Удачи.
  • 0
    Комментариям нужен полноценный редактор?
    • 0
      Не обязательно, работает как с редактором, так и без него, к тому же даже когда он есть — он сильно упрощенный по сравнению с полным.
      • 0
        Сильно упрощенный — это вставка картинки. Ну и может быть жирность. И всё.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.