Pull to refresh

Comments 51

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

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


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


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


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


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

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


use ...
       h;

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

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

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

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

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

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


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

$main = getPath($package, ['browser']) ?: getPath($package, ['jspm', 'main']) ?: getPath($package, ['main']);
Вообще, настройки обычно и оборачивают, в том числе чтобы можно было писать:

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

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


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

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

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

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


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

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


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

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

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

Теперь у вас появилась функция 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']);

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

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

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

Я много слышал об этой «грызне» с CloudFlare, но на сам сайт пускает без проблем. В добавок, сайта нет в Реестре. Впрочем, как и в большинстве случаев :)
Не следование стандартам — это проблема.
Из серии как хотели стандартизировать 2 разных разъема, получилось 3 разъема.
Потому что кто-то считает, что стандарты это необязательно и он не будет им следовать потому, что он может.
Таким образом, повышает энтропию. Причем совершенно без каких либо преимуществ.

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

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

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

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

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

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


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

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


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


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

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


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


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

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

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


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


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


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


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


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


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


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


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


Самый простой и понятный для стороннего разработчика способ — просто 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 архива, который содержит всё необходимое внутри.
И да, ваша реализация стандарта «одиночки» это пожалуй самая дикая и бессмысленно навороченная реализация, которую я видел…


Это всё потому, что это не совсем одиночка, он имеет ещё некоторые полезные свойства, которые часто не важны с точки зрения использования разработчиком, но необходимы для самой системы.
Самый простой и понятный для стороннего разработчика способ — просто 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 и так далее, а у вас все получается в куче, которая к сожалению понятна лишь вам и, пожалуй, богу, что на корню убивает желание взять и работать с вашей системой, без процедуры самобичевания и поиска нужного по тоннам вложенных папок…
Не работал плотно с TinyMCE и «shadow dom», но имею опыт работы с Ckeditor — для меня не составило никакой проблемы форкнуть его без особых изменений, поверх наложив свои конфиги и плагины…


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


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


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


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

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

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

Вот как раз для это и есть, мать его за ногу, композер. Оформили свое ядро как отдельный пакет, опубликовали на packagist, в разворачиваемом (корневом) проекте подключили через require и вышло вполне себе элегантно, да и сборка и развертывание через create-project & update упростились…
Тут вы несколько лукавите. Я думаю что хватило бы наследования 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, если вы понимаете о чём я.
Это только если у вас исключительно PHP код. Здесь же:

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

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

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


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


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


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

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

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

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

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

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

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

Sign up to leave a comment.

Articles