09.06.2016 10:38
nazarpc 51 4500 Источник
Как-то не получалось писать более одной статьи от начала новой ветки (часть 1, часть 2, часть 3), но вот опять есть чего интересного рассказать, ведь вышел первый релиз серии 4.х.

Вкратце обо всём


Первое что хотелось бы сказать — проект был переименован из CleverStyle CMS в CleverStyle Framework. Наконец-то! Больше не будет путаницы между названием и содержимым.

Если серия 2.х началась с существенных изменений на стороне сервера, а 3.х с сопоставимых изменений на клиенте, то 4.х приносит улучшения везде.

На сервере существенно увеличена скорость работы, при том что это full-stack фреймворк, используя HTTP сервер основанный на ReactPHP можно получить скорость генерации страницы НИЖЕ 1мс, быстрее стала генерация HTML в типичных сценариях.
Так же добавилась удобная поддержка вложенных структур в файлах переводов, добавилась поддержка SQLite, PostgreSQL, поддержка работы в качестве PSR7 Middleware (инициализация из PSR7-совместимого request объекта и выдача результата в PSR7-совместимый response объект) и связанные с этим удобные абстракции в самом ядре.

На фронтенде повсеместно используется RequireJS, ряд библиотек, безусловно загружающихся на фронтенде, теперь загружаются только когда непосредственно нужно, добавлены оптимизации для быстрой отрисовки первого кадра (first paint).

На стыке backend и frontend оптимизации построения кэша статики (CSS/JS/HTML), HTTP/2 Server push, Link: <preload> и много другого.

В целом система выглядит как хороший гибридный (не чисто микроядерный, но и не жирный такой) full-stack php фреймворк.

Как всегда, не обошлось без улучшения метрик кода, например, оценки Scrutinizer:)

Polymer и веб-компоненты


Начать можно с того же, с чего прошлая статья — с веб-компонентов.

Сам Polymer всё ещё поставляется патченным, но уже с другой целью. Все важные PR были приняты, 2 не принятых поставляются в качестве runtime патчей и на сам билд не влияют. Зато теперь из сборок Polymer используемых в системе вырезана поддержка Shady DOM, поскольку система использует полную версию Shadow DOM (и полный полифилл там где поддержки нет). Как результат билд существенно меньше оригинального.

Полифилл WebComponents.js так же оптимизирован. Во-первых из него вырезаны все полифилы для IE/Edge (которые подключаются только для упомянутых браузеров), так же WebComponents.js не подключается для Chromium/Chrome, потому что попросту там не нужен.

Сами веб-компоненты используются всё больше, к примеру, сейчас с их использованием отрефакторены модули: Blogs, Comments, Disqus, ну и система давно уже их использует для всего.

Так же система научилась лучше минифицировать HTML файлы, теперь все JS комбинируются и некоторые ошибки ранней реализации были исправлены.

RequireJS (Alameda)


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

RequireJS интегрирован на всех уровнях:
  • сторонние библиотеки, такие как autosize, html5sortable и jssha, поставляемые вместе с ядром, на самом деле используются исключительно как AMD модули и никак иначе (jQuery ожидается быть вынесенной аналогично в 5.x)
  • все компоненты могут использовать AMD модули для собственных нужд очень просто, к примеру, components/modules/Blogs/includes/js/xyz.js можно прозрачно загрузить как модуль Blogs/xyz(подпапки тоже поддерживаются)
  • когда в корне сайта обнаружены bower_components и/или node_modules от Bower/NPM, будет произведен автоматический поиск AMD модулей, так что вы сможете сразу вызывать require(['lodash']).then(function (_) {}) без предварительной конфигурации
  • аналогично корневым Bower/NPM папкам, зависимости, установленные через Composer assets плагин будут обработаны аналогично, становясь доступными по названию без каких/либо путей
  • более того, если вы обратитесь к установленным через Composer assets модулям по абсолютному пути как буд-то они установлены в корень, например, /node_modules/d3/d3 то всё будет работать как будто зависимость и правда установлена именно там!


Таким образом количество обязательно загружаемого кода существенно сократилось, сократится дальше в серии 5.х, и ещё больше потенциала дает разработчику.

IE 10


Время идет, в ядре только __proto__ не используется для совместимости с IE 10, всё остальное бремя совместимости вынесено в новый плагин Old IE, куда в серии 5.х перекочует и поддержка IE 11.

Request/Response, PSR7


Теперь немного о серверной части. Добавились системные объекты cs\Request и cs\Response, оба умеют работать с PSR7, и оба обеспечивают ре-инициализацию по необходимости.
Всё это вместе максимально упростило использования фреймворка в качестве Middleware, что можно увидеть на примере того, как сейчас происходит интеграция с ReactPHP.

Поскольку ре-инициализация обеспечивается автоматически на уровне ядра, стало возможным вообще никогда не пересоздавать системные объекты, а вместо этого только переинициализановать нужные части. Это позволяет достичь генерации страницы быстрее чем за 1мс.

Так же вместе с поддержкой абстракций был написан автономный полностью потоковый парсер multipart запросов, так что выгрузка файлов будет работать с любым методом, а не только POST, так же сайт не сломается при enable_post_data_reading = Off в php.ini (под ReactPHP пока всё ещё нет поддержки выгрузки файлов, очень надеюсь что в ближайшее время выйдет новый релиз с https://github.com/reactphp/http/pull/41 в его составе).

SQLite/PostgreSQL


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

Сессии


С сессиями получилась интересная история с хорошим концом. Исторически в системе используется кастомная система сессий, которая более гибкая чем встроенная, хорошо масштабируется и работает очень быстро.

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

Пространства имен в файлах переводов


Фича напрашивалась давно. Сначала появилась поддержка префиксов в объектах с переводами, потом префиксы начали надоедать в самых переводах, так что теперь можно делать проще:



HTTP/2 Server push, preload


Последние версии Chromium/Chrome поддерживают заголовок/мета-тэг preload, которые говорит браузеру что этот ресурс вот 100% нужен странице, грузи его даже если пока не понял для чего, я точно знаю что он будет нужен.
Этот же атрибут используют nghttp2 и CloudFlare для HTTP/2 Server push.

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

CLI интерфейс


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

Обновления


Компоненты Blogs, Comments, Composer, Disqus, Uploader, Composer assets и TinyMCE используют самые последние удобные фичи ядра, и являются примерами того, как стоит делать компоненты в современной версии фреймворка. Остальные компоненты по большей части просто портировались для совместимости с новыми версиями и не используют потенциал системы на 100%, но будут в последующих обновлениях.

Сторонние зависимости были обновлены до актуальных версий на время релиза.

Документация


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

Scrutinizer


Не знаю, много это или мало, но с 7.74 до 8.15 оценка поднялась, да и распределение существенно поменялось:



Видео уроки для разработчиков


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

Желающие пообщаться чатике могут сделать это в Gitter.
Код на GitHub, документация в папке docs.
Запустить пощупать можно одной строчкой с помощью Docker (лучше использовать Firefox, Chromium не желает выставлять cookie на localhost):

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

Также новая версия используется на cleverstyle.org (с HTTP/2 и прочими радостями).
Поделиться с друзьями
-->

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


  1. cawakharkov
    09.06.2016 15:57
    #9650142
    +1

    Я ни на что не намекаю, но http://www.php-fig.org/.


    1. nazarpc
      09.06.2016 16:19
      #9650214

      То есть про PSR7 я знаю, а про PHP-FIG нет?)


      1. cawakharkov
        09.06.2016 16:23
        #9650222

        Судя по коду — нет)


        1. nazarpc
          09.06.2016 16:38
          #9650270
          +1

          А что, знание всех принятых PSR должно обязательно выливаться в безприкословное их использование?


          Я хорошо знаю что они являют собой, но не использую их сознательно. Тем не менее поддерживаю их интеграцию с ядром (так же как ядру не нужен Composer, но он прозрачно интегрируется при наличии, аналогично есть интеграция с Bower, NPM и другими проектами, разрабатываемыми сообществом).


          Вот вам пример: PSR7. Отличная идея, хотя мне не особенно нравится реализация, особенно прослойки в виде объектов потоков. Иногда читая исходники популярных реализаций вроде Zend Diactoros у меня прямо слезы наворачиваются. А вот принимать патчи проекты тоже не спешат. Вот в CleverStyle Framework собственная, более эффективная, реализация Request/Response, тем не менее есть возможность взаимодействия с PSR7-совместимыми интерфейсами.


          Похожая ситуация с PSR6 — кучу всего нагородили, а поддержки пространств имен или тэгов нет, инкрементов тоже нет. В итоге даже прослойку совместимости написать в общем случае не получится.


          Так что да, я считаю что в определённых случаях могу сделать лучшую реализацию. Я имею собственную голову и пользуюсь ею для критической оценки любого PSR или проекта, каким бы авторитетным не был его автор.


          1. cawakharkov
            09.06.2016 16:47
            #9650280
            +2

            Ваше право.
            Но лично мне как разработчику приятно видеть когда какой-то новый инструмент использует единые рекомендации. Это облегчает жизнь всем его пользователям.
            А например от использования в коде @, неймспейсов с маленькой буквы и вот таких вещей:


            use ...
       h;

            Меня коробит.


            1. nazarpc
              09.06.2016 17:28
              #9650362

              @ используется только вместо isset(xyz) ? xyz : whatever, пока не будет убрана поддержка PHP 5.6, где нет ??, иначе временами читабельность катастрофически падает. Остальное дело вкуса.


              1. cawakharkov
                09.06.2016 17:33
                #9650374

                Так в этом то и дело, общие стандарты и их соблюдение упрощает жизнь всем.


              1. TheShock
                09.06.2016 18:33
                #9650492
                +1

                @ используется только вместо isset(xyz)? xyz: whatever

                Вы это серьезно сейчас, да?


                1. nazarpc
                  09.06.2016 18:38
                  #9650512

                  Совершенно серьезно, а что?


                  В качестве задания предлагаю вам переписать без @ следующий участок и сравнить ментальную нагрузку во время чтения. Если у вас получится написать что-то что легче для чтения — буду рад изменить код у себя.


                  1. TheShock
                    09.06.2016 19:35
                    #9650592

                    $main = getPath($package, ['browser']) ?: getPath($package, ['jspm', 'main']) ?: getPath($package, ['main']);


                    1. TheShock
                      09.06.2016 19:36
                      #9650594

                      Вообще, настройки обычно и оборачивают, в том числе чтобы можно было писать:

                      $main = $config->get('browser') ?: $config->get('jspm.main') ?: $config->get('main');


                      1. nazarpc
                        09.06.2016 19:45
                        #9650612

                        Эта функция вызывается много раз для каждого найденного Bower/NPM пакета. Можно, конечно, оборачивать каждый раз в объект конфигурации, но тогда вам нужно ещё больше информации держать в голове.


                        Это по-моему как раз тот случай, когда Antony Ferrara рассуждает о simple vs easy


                        1. TheShock
                          09.06.2016 19:53
                          #9650624

                          Глушите ошибки дальше)


                          1. nazarpc
                            09.06.2016 19:56
                            #9650630

                            Какие ошибки? Там самый обычный массив, там даже ArrayAccess объекта быть не может. Это полная аналогия ?? из PHP7 в данном контексте, разве я не прав?)


                        1. Fesor
                          09.06.2016 19:57
                          #9650636
                          +1

                          У вас как раз simple а не easy. Когда ваш интерфейс требует париться о таких проблемах и использовать оператор подавления ошибок мне кажется это говорит о том что интерфейс не удобен.


                          В вашем случае отсутствие какой-либо структуры в конфиге явилось в виде кастылей. Не хватает консистентности, у вас 3 разных варианта объявить что-то одно.


                          1. nazarpc
                            09.06.2016 20:04
                            #9650642

                            О том же я и говорю. Simple.
                            Хотя ничего сложного там тоже нет.

                            В вашем случае отсутствие какой-либо структуры в конфиге явилось в виде кастылей. Не хватает консистентности, у вас 3 разных варианта объявить что-то одно.


                            Не вникая в суть вещей вы идете слишком далеко с выводами.

                            В данном конкретном случае это не у меня 3 разных варианта объявить что-то. Это я поддерживаю 2 варианта оформления package.json из NPM и дополнительно конфиг из JSPM. Если есть жалобы на то, что там разные форматы — можете жаловаться им напрямую. Если желаете обрабатывать подобные варианты в Symfony вручную — тоже удачи вам, но скорее всего у вас выйдет что-то аналогичное, ибо раз что-то нужно проверить в трех местах с определённым приоритетом, то это нужно сделать так или иначе.


                            1. Fesor
                              09.06.2016 22:42
                              #9650844

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


                    1. nazarpc
                      09.06.2016 19:42
                      #9650604
                      -1

                      Теперь у вас появилась функция getPath, которую тоже нужно найти и прочесть (скорее всего она будет не в глобальной области видимости, а метод класса, что добавит $this->), а ещё скобки лучше вернуть, ибо ассоциативность тернарного оператора.
                      ИМХО, конечно, но


                      $main = @$package['browser'] ?: (@$package['jspm']['main'] ?: @$package['main']);

                      как абсолютно самодостаточный пример мне читать гораздо легче чем


                      $main = $this->getPath($package, ['browser']) ?: ($this->getPath($package, ['jspm', 'main']) ?: $this->getPath($package, ['main']));

                      В PHP 7 код будет переписан как


                      $main = $package['browser'] ?? ($package['jspm']['main'] ?? @$package['main']);


        1. kitcat
          09.06.2016 17:21
          #9650340

          Вы намекаете на github.com/FriendsOfPHP/PHP-CS-Fixer?


          1. cawakharkov
            09.06.2016 17:29
            #9650366

            Я намекаю на вещи упомянутые в моём прошлом комменте.


  1. bustEXZ
    09.06.2016 16:09
    #9650178

    Странно, но cleverstyle.org блокируется моим провайдером «в соответствии с требованиями Законодательства России?скои? федерации.». При этом сам хром сказал, что это не очень то и доверительный сайт. Интересно с чем это может быть связано?)


    1. nazarpc
      09.06.2016 16:11
      #9650186

      Полагаю, это связано с Законодательством Российской Федерации)
      А если серьезно, то вероятнее всего не нравится CloudFlare, но тут я ничего поделать не могу.


      1. bustEXZ
        09.06.2016 16:19
        #9650212

        Я много слышал об этой «грызне» с CloudFlare, но на сам сайт пускает без проблем. В добавок, сайта нет в Реестре. Впрочем, как и в большинстве случаев :)


  1. gaaarfild
    09.06.2016 18:22
    #9650460
    +1

    Не следование стандартам — это проблема.
    Из серии как хотели стандартизировать 2 разных разъема, получилось 3 разъема.
    Потому что кто-то считает, что стандарты это необязательно и он не будет им следовать потому, что он может.
    Таким образом, повышает энтропию. Причем совершенно без каких либо преимуществ.


    1. nazarpc
      09.06.2016 18:24
      #9650466
      +1

      Энтропия неизбежно необходима для развития, мы же не хотим чтобы развитие технологий остановилось здесь и сейчас. Почему вы видите здесь проблему?


      1. gaaarfild
        09.06.2016 18:31
        #9650484
        +1

        Потому что есть полезная энтропия, а есть та, которая просто является бесполезным побочным эффектом.
        Я не думаю, что можно в Кодстайле PHP придумать что-то действительно новое и удобное. И к изобретениям новым ик развитию это не приведет.
        Или я все таки чего-то тут не замечаю? :)


        1. nazarpc
          09.06.2016 18:34
          #9650496

          По вашему стиль кодирования это основная ценность проекта? Или то, что стиль кодирования вообще на изобретение как-то влияет? Стиль кодирования вещь субъективная. Есть откровенно ужасные стили, а есть просто другие. Мое мнение, что текущий стиль кодирования как минимум не ужасен, а лично для меня он более приятен.


          1. gaaarfild
            09.06.2016 18:39
            #9650514
            +1

            По-моему, единый стиль кодирования позволит проекту быть поддерживаемым различными технологиями. Той же автозагрузкой композера.
            Потому что классы/переменные будут называться предсказуемо, а не так как очередной кодер решил.
            Предсказуемо не для человека, а для других программ.
            Так как у других программ нет абстрактного мышления как у нас с вами.


  1. Fesor
    09.06.2016 18:41
    #9650518
    +3

    • IoC для слабаков. Отсутствие оного мотивировано тем что "зависимости не всегда используются и зачем их за зря инстанциировать". Снижать связанность, повышать зацепление объектов? Зачем! Вместо этого все зависимости глобальны (леревелевские богомерзские "фасады" в весьма так себе исполнении), зачем париться с управлением зависимостями.
    • Кастыли с миксинами и патчингом, полиморфизм пустили по звезде
    • нет композера, то есть удобный способ с composer create-project не прокатит. Мотивировано это тем что "мне не нужен композер". Автозагрузчик совместим и то хорошо.
    • соблюдать PSR стандарты для конформистов. Делаем как привыкли

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


    1. nazarpc
      09.06.2016 19:01
      #9650544
      -3

      IoC для слабаков. Отсутствие оного мотивировано тем что "зависимости не всегда используются и зачем их за зря инстанциировать". Снижать связанность, повышать зацепление объектов? Зачем! Вместо этого все зависимости глобальны (леревелевские богомерзские "фасады" в весьма так себе исполнении), зачем париться с управлением зависимостями.


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

      Зависимости в виде компонентов вполне себе могут быть заменены на альтернативные. Каждый компонент кроме названия имеет ряд функциональностей, которые могут быть использованы для вызова классов. Например, компонент XYZ, который предоставляет функциональность ABC имеет класс cs\modules\XYZ\MyClass, тогда этот же класс можно вызвать как cs\modules\ABC\MyClass. Если у вас несколько компонентов предлагают одну и ту же функциональность — вы можете таким образом иметь несколько классов с общим интерфейсом и использовать их как взаимозаменяемые.
      Кастыли с миксинами и патчингом, полиморфизм пустили по звезде


      Повторюсь, это крайние меры, которые существуют для очень крайних случаев. Оно вам будет нужно чуть чаще чем никогда. В том же PHP есть runkit, но вы же не используете его в каждом проекте, верно же? Это того же уровня функциональность.
      нет композера, то есть удобный способ с composer create-project не прокатит. Мотивировано это тем что "мне не нужен композер". Автозагрузчик совместим и то хорошо.


      Вот кстати, create-project планируется, но пока не успел его сделать. А для ядра системы Composer и правда не является необходимостью (для некоторых компонентов он нужен).

      Я понимаю что вы говорите, понимаю отношение к новым фреймворкам у вас и сообщества в целом. Но большинство комментариев упираются в слишком поверхностное ознакомление (боюсь что вы недооцениваете количество того, что было предусмотрено, например что папка .idea в репозитории совершенно не случайно) и/или то, что любой стиль кодирования, который не PSR из рук вон плохой, не поддерживаемый и совершенно не читаемый. Что откровенно говоря не правда.


      1. Fesor
        09.06.2016 19:05
        #9650550
        +2

        Но большинство комментариев упираются в слишком поверхностное ознакомление


        Мне достаточно судить по следующим параметрам:
        • размер комьюнити: 1 человек


        Что автоматически взмывает риски до небес. Намного дешевле будет взять composer, поставить php-di, psr-7 совместимый кернел или хотя бы symfony/http-kernel, взять роутер удобный и простой (fastroute или подобные), библиотеку для валидации данных и просто делать дела. А что бы не тратить время на булшит вроде "хлебных крошек" (тут в соседнем топике человек считает что это важно для фреймворков...) просто взять какой ангуляр или эмбер и сделать толстый клиент с серверсайд пререндрингом. Выходит сильно дешевле и намного более гибко. Естественно если у разработчика есть опыт работы с этим.


        1. nazarpc
          09.06.2016 19:34
          #9650590
          -1

          А вот на это у меня нечего противопоставить. Я не маркетолог, и с развитием сообщества у меня мягко говоря сложности. Есть идеи как удвоить?


      1. Fesor
        09.06.2016 19:11
        #9650560

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


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


        мне просто это напоминает процедурное программирование. Глобальное состояние, статика, классы… я люблю объекты и сообщения между ними.
        вы можете таким образом иметь несколько классов с общим интерфейсом и использовать их как взаимозаменяемые.


        Декораторы у вас можно делать?
        В том же PHP есть runkit, но вы же не используете его в каждом проекте, верно же?


        вообще не пользовался. Это полезно только при очень жестких формах рефакторинга легаси кода.


        1. nazarpc
          09.06.2016 19:31
          #9650586
          +1

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


          В большинстве шаблонизаторов (коих во фреймворке из коробки 0) можно при желании писать PHP код в шаблонах, а значит не только делать запросы в БД, но и вызывать сторонние API и прочее. Делать это или нет — ИМХО вопрос образования разработчика.
          Но в целом вы правы, любой может вызвать любого когда и если это ему нужно.
          Декораторы у вас можно делать?


          А почему нет?
          вообще не пользовался. Это полезно только при очень жестких формах рефакторинга легаси кода.


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


  1. zenn
    09.06.2016 18:54
    #9650536
    +1

    Пожалуй у этого автора код не полностью плачевен, по сравнению с публикациями за последний месяц в тег php. Но может вам все же стоит задуматься над PSR, composer'ом (в описании у вас указана его поддержка, но какими путями я так и не понял), избавиться от излишних Singleton'ов и попробовать следовать принятым паттернам проектирования?
    Мне честно не ясно, почему у вас «сторонние» приложения раскиданы по всему проекту: раз, два, три — как же вы будете следить за их версиями, обновлениями, безопасностью? Это же дико как не удобно, мне никак не понять смысл использования велосипеда и билдера — это же какой-то дикий ад…
    И да, ваша реализация стандарта «одиночки» это пожалуй самая дикая и бессмысленно навороченная реализация, которую я видел…


    1. nazarpc
      09.06.2016 19:19
      #9650576
      -1

      код не полностью плачевен


      Спасибо, это лучшее, что о нём писали под этой статьей:)
      в описании у вас указана его поддержка, но какими путями я так и не понял


      Самый простой и понятный для стороннего разработчика способ — просто composer require abc в корне проекта. Система подхватит vendor/autoload.php если он существует, то есть никакой магии здесь нет.
      Мне честно не ясно, почему у вас «сторонние» приложения раскиданы по всему проекту: раз, два, три — как же вы будете следить за их версиями, обновлениями, безопасностью?


      ОК, здесь тоже всё не случайно:
      • TinyMCE поставляется патченный, это единственный в своем роде полноценный WYSIWYG редактор (PR upstream), который работает внутри Shadow DOM + интеграция с фреймворком; стоковая версия никак не подходила, если вам Shadow DOM не нужна — можете через Bower/NPM подключать стоковую
      • HybridAuth так же патченный, поскольку стабильная версия много взаимодействует с суперглобальными переменными, в то время как фреймворк умеет не умирать и работать в режиме высокопроизводительного HTTP сервера, что требует Request/Response прослойки в HybridAuth, изменения в библиотеке документированы
      • в thirdparty лежит патченная версия PhpMailer (там конструктор был лишним) и некоторые другие сторонние компоненты, необходимые для автономной установки, за уши как причину можно притянуть нашумевшую историю с NPM, хотя это и не является каким-либо фактором в данном случае


      За безопасностью слежу с помощью десятков RSS/Atom лент из GitHub и не только, в которых слежу за всеми используемыми мной библиотеками во всех поддерживаемых мной проектах и внимательно читаю release notes каждого релиза в течении максимум нескольких часов после выхода.

      Сборщик установочных пакетов является универсальным способом для:
      • автономной установки системы и компонентов в CLI/графическом режиме
      • автономного обновления системы и компонентов


      То есть дистрибутив — это единственный файл вроде SFX архива, который содержит всё необходимое внутри.
      И да, ваша реализация стандарта «одиночки» это пожалуй самая дикая и бессмысленно навороченная реализация, которую я видел…


      Это всё потому, что это не совсем одиночка, он имеет ещё некоторые полезные свойства, которые часто не важны с точки зрения использования разработчиком, но необходимы для самой системы.


      1. zenn
        09.06.2016 19:45
        #9650610

        Самый простой и понятный для стороннего разработчика способ — просто composer require abc в корне проекта. Система подхватит vendor/autoload.php если он существует, то есть никакой магии здесь нет.

        Ну… тогда можно сказать что абсолютно все разработки на php поддерживают композер. Речь как раз таки шла о вашем движке и о тех сторонних приложениях/библиотеках, которые он использует и об удобности контроля их версий…
        TinyMCE поставляется патченный, это единственный в своем роде полноценный WYSIWYG редактор (PR upstream), который работает внутри Shadow DOM + интеграция с фреймворком; стоковая версия никак не подходила, если вам Shadow DOM не нужна — можете через Bower/NPM подключать стоковую

        Не работал плотно с TinyMCE и «shadow dom», но имею опыт работы с Ckeditor — для меня не составило никакой проблемы форкнуть его без изменений, поверх наложив свои конфиги и плагины…
        HybridAuth так же патченный, поскольку стабильная версия много взаимодействует с суперглобальными переменными, в то время как фреймворк умеет не умирать и работать в режиме высокопроизводительного HTTP сервера, что требует Request/Response прослойки в HybridAuth, изменения в библиотеке документированы

        Опять же, что мешало вам наследовать реализацию HybridAuth, в которой содержался злополучный exit/die или throw new Exception() и в своей прослойке переработать/изменить эти методы?
        в thirdparty лежит патченная версия PhpMailer (там конструктор был лишним) и некоторые другие сторонние компоненты, необходимые для автономной установки

        Ну что ж вы, там далеко не только PhpMailer, там есть еще ряд занятных библиотек. Опять же, разве не было иного способа, кроме как тащить все это путем копирования в проект?

        К чему я все это — такой «разброс» содержимого «сторонних» библиотек по всему проекту по началу вводит в недоумение, а в конце-концов будет очень сильно сбивать с толку того, кто будет работать с вашей системой, а для вас это выльется в сотни человека-часов потраченных на то, что composer и прослойка extend-а делает автоматически… Обратите внимание, большинство проектов пытаются следовать хоть какому-то, но унифицированному стилю — 3'rd party — значит vendor, расширение/патчинг — значит extend, автозагрузка — psr0/4 и так далее, а у вас все получается в куче, которая к сожалению понятна лишь вам и, пожалуй, богу, что на корню убивает желание взять и работать с вашей системой, без процедуры самобичевания и поиска нужного по тоннам вложенных папок…


        1. nazarpc
          09.06.2016 19:54
          #9650626

          Не работал плотно с TinyMCE и «shadow dom», но имею опыт работы с Ckeditor — для меня не составило никакой проблемы форкнуть его без особых изменений, поверх наложив свои конфиги и плагины…


          Если вы не работали плотно с Shadow DOM то вы не сможете адекватно оценить масштаб трагедии:) Но в целом, если вам оно не нужно — используйте себе CKEditor, никаких проблем. Просто вы спросили почему — я ответил что это не случайно.
          Опять же, что мешало вам наследовать реализацию HybridAuth, в которой содержался злополучный exit/die или throw new Exception() и в своей прослойке переработать/изменить эти методы?


          Если кратко — то мешало то, как реализован HybridAuth. Мне пришлось бы всё равно делать копию если не всего HybridAuth, то его части как минимум. А набор простых патчей поддерживать проще. Ну и версия 3.х, надеюсь, когда-то выйдет в релиз, там с этим всё гораздо лучше.
          Ну что ж вы, там далеко не только PhpMailer, там есть еще ряд занятных библиотек. Опять же, разве не было иного способа, кроме как тащить все это путем копирования в проект?


          Конечно, способы были, тот же Composer. Но было принято решение в пользу автономности.
          а у вас все получается в куче


          Не совсем. core это системная папка, вы туда никогда не лезете, она используется ядром. Можете делать вид, что её не существует. Каждый модуль в components/modules и плагин в components/plugins вещь автономная и совершенно необязательная. Ставите и разбираетесь только если оно вам явно нужно. Относящиеся к модулю файлы никогда не вылазят за рамки его директории, нет такого что все view в одной куче, контроллеры лежат в другом месте в другой куче и так далее. Пока разве что на слово можете мне поверить, но ничего сложного в этом нет, тем более не сложнее чем в любом другом фреймворке. Везде есть местные правила организации.


          1. zenn
            09.06.2016 20:09
            #9650650

            Если кратко — то мешало то, как реализован HybridAuth. Мне пришлось бы всё равно делать копию если не всего HybridAuth, то его части как минимум. А набор простых патчей поддерживать проще. Ну и версия 3.х, надеюсь, когда-то выйдет в релиз, там с этим всё гораздо лучше.

            Тут вы несколько лукавите. Я думаю что хватило бы наследования 3х классов через extend и перезаписи в каждом по 1-2 методов.
            Конечно, способы были, тот же Composer. Но было принято решение в пользу автономности.

            И тут вы опять лукавите. Автономность? Ну храните себе vendor прям в проекте на github(хотя и это не хороший тон, но не хуже текущего уж точно) или линкуйте на свои форки (их куда проще будет обновлять даже в таком виде), в чем беда то?
            core это системная папка, вы туда никогда не лезете, она используется ядром

            Вот как раз для это и есть, мать его за ногу, композер. Оформили свое ядро как отдельный пакет, опубликовали на packagist, в разворачиваемом (корневом) проекте подключили через require и вышло вполне себе элегантно, да и сборка и развертывание через create-project & update упростились…


            1. nazarpc
              09.06.2016 20:20
              #9650664

              Тут вы несколько лукавите. Я думаю что хватило бы наследования 3х классов через extend и перезаписи в каждом по 1-2 методов.


              Только если HybridAuth не вызывает и наследует классы по имени напрямую. Тогда всё становится слегка сложнее:)
              И тут вы опять лукавите. Автономность? Ну храните себе vendor прям в проекте на github(хотя и это не хороший тон, но не хуже текущего уж точно) или линкуйте на свои форки (их куда проще будет обновлять даже в таком виде), в чем беда то?


              Тогда в идеале vendor не нужно трогать. А значит закоммитится куча мусора типа тестов, документации и прочего, тогда как мне просто нужен 1 файл. Но в целом согласен что это не лучший вариант. На каком-то этапе в thirdparty были composer.json и vendor, но мне показалось что текущий вариант всё же лучше. Если есть какой-либо третий вариант — я с радостью его рассмотрю.
              Вот как раз для это и есть, мать его за ногу, композер. Оформили свое ядро как отдельный пакет, опубликовали на packagist, в разворачиваемом (корневом) проекте подключили через require и вышло вполне себе элегантно, да и сборка и развертывание через create-project & update упростились…


              Это только если у вас исключительно PHP код. Здесь же:
              • структура самого проекта
              • схемы БД должны быть обновлены при обновлении системы и компонентов
              • статические ресурсы CSS/JS/HTML
              • иногда при установке/обновлении есть какие-то интерактивные процессы, которые гораздо проще и удобнее реализовать в Web интерфейсе, чем в виде плагинов в Composer


              С использованием библиотек вы в проекте сами решаете как всё это делать, здесь же этим может заниматься фреймворк (если вас устраивает то, как он это делает), и изворачиваться распаковкой фреймворка во-внеvendor либо разработкой компонентов внутри vendor/cleverstyle/framework/components/modules выглядит как-то совсем по-идиотски.

              Я уже приводил аналогию в одном чате. Symfony это как LFS, CleverStyle Framework же скорее Ubuntu/Fedora, если вы понимаете о чём я.


              1. zenn
                09.06.2016 20:36
                #9650684

                Это только если у вас исключительно PHP код. Здесь же:

                Композер умеет исполнять калбэки при create-project / прочих командах, проблемы в этом нет.
                С использованием библиотек вы в проекте сами решаете как всё это делать, здесь же этим может заниматься фреймворк (если вас устраивает то, как он это делает), и изворачиваться распаковкой фреймворка во-внеvendor либо разработкой компонентов внутри vendor/cleverstyle/framework/components/modules выглядит как-то совсем по-идиотски

                Причем здесь это? Разве компоненты относятся жестко к ядру? Это же уровень приложений, как не крути. Отсюда, функционал «ядра» (выше вам давали ссылки на то, что такое классический kernel) действительно должен быть неизменным и хранится глубоко в недрах vendor'а со своими тестами. А стандарт автозагрузки PSR позволит вам хранить ваши компоненты практически где угодно, при условии инициации загрузчика composer'a и следования стандарту автозагрузки.
                CleverStyle Framework же скорее Ubuntu/Fedora, если вы понимаете о чём я.

                А вы понимаете о чем вы? Вы сравниваете операционную систему на ядре linux с интерпритируемым приложением на скриптовом языке… При том, что вы не используете возможности того самого языка и разработок к нему, которые признали 99% всех крупных игроков, аргументируя это надуманными предлогами. Еще раз, посмотрите на symfony, yii2, laravel и их архитектуру, может быть все же заблуждается не все комьюнити, а вы?


                1. nazarpc
                  09.06.2016 20:53
                  #9650696

                  Композер умеет исполнять калбэки при create-project / прочих командах, проблемы в этом нет.


                  А ещё есть плагины, которыми можно много чего расширить в самом Composer, но сложность разработки и поддержки всего этого будет намного выше. Тем более разработка фреймворка в изначальном виде началась ещё до первого коммита в репозитории CleverStyle Framework это не просто несколько файлов исходников, это целая система зависимостей и куча событий, которые генерируются в системе при манипуляции с компонентами. Всё не так просто, как может показаться изначально. Но и не так сложно, как оно устроено внутри Composer (при этом размер всего фреймворка сопоставим с размером Composer).
                  Причем здесь это? Разве компоненты относятся жестко к ядру? Это же уровень приложений, как не крути. Отсюда, функционал «ядра» (выше вам давали ссылки на то, что такое классический kernel) действительно должен быть неизменным и хранится глубоко в недрах vendor'а со своими тестами. А стандарт автозагрузки PSR позволит вам хранить ваши компоненты практически где угодно, при условии инициации загрузчика composer'a и следования стандарту автозагрузки.


                  Компоненты не относятся (точнее есть один системный компонент, называется System, обеспечивает админку ядра и вещи вроде robots.txt), но структура всего приложения вполне задается фреймворком.
                  А вы понимаете о чем вы? Вы сравниваете операционную систему на ядре linux с интерпритируемым приложением на скриптовом языке… При том, что вы не используете возможности того самого языка и разработок к нему, которые признали 99% всех крупных игроков, аргументируя это надуманными предлогами. Еще раз, посмотрите на symfony, yii2, laravel и их архитектуру, может быть все же заблуждается не все комьюнити, а вы?


                  Я провожу аналогию между тем, что являют собой две системы на базе ядра Linux (одна собрана из исходников, другая готовый дистрибутив, который вы записаваете на USB и просто устанавливаете в графическом режиме), и что являют собой два приложения, написанные на интерпретируемом языке (но один с использованием типичного компонентного фреймворка, а другой с использованием CleverStyle Framework). Отличие в этих парах достаточно явно показывает фундаментальные отличия в подходах.

                  Более того, я не считаю что кто-то прямо заблуждается. Но я считаю, что альтернативные подход может быть лучше во многих сценариях.


  1. zenn
    09.06.2016 20:36
    #9650680

    del, ошибся веткой.


  1. IvanPanfilov
    10.06.2016 08:10
    #9651038

    чем это лучше wordpress?

    еще один ненужный фреймворк.


    1. Drim
      10.06.2016 13:24
      #9651538

      Wordpress это не фреймворк, а CMS.


      1. IvanPanfilov
        11.06.2016 17:54
        #9652694

        был же CMS. т.е. оттуда удалили все возможности CMS?
        и теперь их надо реализовывать самому?
        тогда и вовсе не имеет никаких преимуществ.


        1. nazarpc
          11.06.2016 17:57
          #9652696
          +1

          Что-то не понятно, к чему этот комментарий


          1. Fesor
            11.06.2016 18:22
            #9652710

            переведу. Раньше у вас было CleverStyle CMS, теперь вы величаете ее Framework. В чем координальные отличия, насколько я понимаю код один и тот же.


            1. nazarpc
              11.06.2016 18:25
              #9652714

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


              1. Fesor
                11.06.2016 18:48
                #9652718

                То есть это CMF. Так?


                1. nazarpc
                  11.06.2016 18:52
                  #9652722

                  Если посмотреть на Drupal, который, по-моему, самая известная штука, называемая CMF, то скорее нет, чем да.
                  То, что для фреймворка есть готовые компоненты ещё не делает его CMF (даже при том, что они в одном репозитории), никакой конечной функциональности для пользователя ядро из коробки не предоставляет.