Комментарии 16
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Еще один велосипед, благодаря которым потом говорят что в сообществе PHP не программисты. Ни о «стандарте» PSR-0, ни о PSR-1 автор видимо не слышал, код читать невозможно, когда в if происходит запрос в бд, который в чистом виде прописан прямо там же — это ужас пример.
И как можно читать такое?
На демо сайте что-то странное со временем (оно в разных форматах везде, и как пользователь может задать свою Timezone вообще непонятно)
Иерархия ужасна, вообще нелогична. Хорошая попытка, но это использовать нельзя
И как можно читать такое?
На демо сайте что-то странное со временем (оно в разных форматах везде, и как пользователь может задать свою Timezone вообще непонятно)
Иерархия ужасна, вообще нелогична. Хорошая попытка, но это использовать нельзя
О PSR знаю прекрасно, собрались представители сообщества PHP и решили выработать компромиссные правила. Тем не менее это рекомендация, которая в некоторых местах мне не нравится. В связи с этим их конвенции не наследуются, я придерживаюсь другого, но тоже весьма однородного, стиля, что не является преступлением.
На счёт запроса в БД — ничего ужасного, обычный запрос с prepared statements, PDO не используется, используется более быстрый вариант — чистые SQL запросы, которые читать, имхо, проще, да и синтаксис SQL знаком всем, даже тем кто не пишет на PHP. Тем более проще когда делаются сложные выборки из БД с участием нескольких таблиц. К тому же не нужно помнить о подводных камнях PDO, получаете ровно то, что просите.
Читать можно легко и с удовольствием, если использовать IDE где одна табуляция имеет ширину 4 пробела, а не 8 как на GitHub.
Время в комментариях отображается по разному, в зависимости от того, когда сделан комментарий. Если недавно — отображается время, если давно — то полная дата. Форматы настраиваются в локализации. Часовый пояс настраивается как на уровне всей системы тут, так и в профиле пользователя если он этого хочет тут.
На счёт иерархии я бы хотел услышать подробнее.
На счёт запроса в БД — ничего ужасного, обычный запрос с prepared statements, PDO не используется, используется более быстрый вариант — чистые SQL запросы, которые читать, имхо, проще, да и синтаксис SQL знаком всем, даже тем кто не пишет на PHP. Тем более проще когда делаются сложные выборки из БД с участием нескольких таблиц. К тому же не нужно помнить о подводных камнях PDO, получаете ровно то, что просите.
Читать можно легко и с удовольствием, если использовать IDE где одна табуляция имеет ширину 4 пробела, а не 8 как на GitHub.
Время в комментариях отображается по разному, в зависимости от того, когда сделан комментарий. Если недавно — отображается время, если давно — то полная дата. Форматы настраиваются в локализации. Часовый пояс настраивается как на уровне всей системы тут, так и в профиле пользователя если он этого хочет тут.
На счёт иерархии я бы хотел услышать подробнее.
PSR «стандарты» были сделаны не просто так, а чтобы любой разработчик открыв любой проект, мог за пару минут разобраться в его структуре. К примеру PSR-0 либо PSR-4 дает нам единый стиль именования и размещения файлов компонента. PSR-1 задает стиль кодирования, хотите использовать табы — используйте Smart табуляцию. Именование переменных стоит вести в одном виде.
Насчет запросов к БД, то возможно стоит использовать подход DRY? Не повторять одно и то же в каждом файле, как только что-то добавится в таблицу, вам надоест переписывать полностью во всех местах. Хотя бы сделать провайдеры либо репозитории (вынести эти все запросы согластно таблиц в свои места, и менять удобно, и код чище).
Читать невозможно не только из-за табуляции, а из-за именования переменных, что обозначает переменная $L? А почему она не называется $foo? То-есть это нормально?
Я о том, что стиль времени в виде 20:30 в посте, а 8:30 pm в комментариях это нормально? Вынести логику вывода в одно место, в виде хелпера, и то проще была бы.
Все очень плохо, если одним предложением. Все раскидано в разных местах, очень много повторений, добавление поста в блог и редактирование в разных файлах, а по методам которые они вызывают там вообще удаление происходит (о_О). И если не заметить к примеру add_internal то можно подумать что он удаляет а не создает.
Еще раз скажу, поддержка такого проекта будет стоить не малых средств и времени, так как правки нужно делать в вообще неожиданных местах.
Насчет запросов к БД, то возможно стоит использовать подход DRY? Не повторять одно и то же в каждом файле, как только что-то добавится в таблицу, вам надоест переписывать полностью во всех местах. Хотя бы сделать провайдеры либо репозитории (вынести эти все запросы согластно таблиц в свои места, и менять удобно, и код чище).
Читать невозможно не только из-за табуляции, а из-за именования переменных, что обозначает переменная $L? А почему она не называется $foo? То-есть это нормально?
Я о том, что стиль времени в виде 20:30 в посте, а 8:30 pm в комментариях это нормально? Вынести логику вывода в одно место, в виде хелпера, и то проще была бы.
Все очень плохо, если одним предложением. Все раскидано в разных местах, очень много повторений, добавление поста в блог и редактирование в разных файлах, а по методам которые они вызывают там вообще удаление происходит (о_О). И если не заметить к примеру add_internal то можно подумать что он удаляет а не создает.
Еще раз скажу, поддержка такого проекта будет стоить не малых средств и времени, так как правки нужно делать в вообще неожиданных местах.
Framework Interop Group как бы из названия намекает, для чего создана. Так как данный движок не является фреймворком в чистом виде, и не предполагает что ядро будут кастомизировать в каждом проекте — отсюда выплывает ряд соответствующих особенностей архитектуры, повышенный уровень связности, а как следствие меньше избыточных уровней абстракции и выше общее быстродействие.
В большинстве модулей есть один или несколько классов, которые содержать ряд методов, и с помощью этих методов производятся всевозможные манипуляции. Таким образом явные запросы в БД в большинстве своем не пишутся где-либо за рамками этих классов. Например, https://github.com/nazar-pc/CleverStyle-CMS/tree/master/components/modules/Commentsмодуль комментариев, который интегрируется в блоги, и потенциально другие модули при необходимости. В нём запросы есть только в Comments.php, где лежит один класс, больше нигде запросов нет, только вызовы методов. К тому же, все названия полей перечисляются явно, потому при обновлении структуры БД места где новые поля не используются не сломаются, и не потребуют редактирования.
Переменные с большой буквы (с одним исключением) именуются с большой буквы, к тому же если посмотреть на определение переменной:
Дополнительных вопросов возникнуть не должно. В данном конкретном случае название класса слишком длинное, если вам так больше понравится — можно использовать функцию __(), которая является оберткой, и привычна многим.
По поводу даты — спасибо, вы нашли опечатку, исправлено.
Как раз всё лежит в вполне предсказуемых местах. Всё что касается модуля только в его директории, системные классы и функции в core относительно корня. Добавление и редактирование поста в разных файлах, по скольку это разные страницы. Вв фреймворке, вероятнее всего, это были бы два метода (action) одного контроллера + две (или одна) view, а здесь это два файла. Непосредственно манипуляции всё равно производятся в одном классе, остальное — графическая обертка над этим + права доступа. На счёт удаления не понял о чём именно речь, поиск по проекту «add_internal» не нашел.
В большинстве модулей есть один или несколько классов, которые содержать ряд методов, и с помощью этих методов производятся всевозможные манипуляции. Таким образом явные запросы в БД в большинстве своем не пишутся где-либо за рамками этих классов. Например, https://github.com/nazar-pc/CleverStyle-CMS/tree/master/components/modules/Commentsмодуль комментариев, который интегрируется в блоги, и потенциально другие модули при необходимости. В нём запросы есть только в Comments.php, где лежит один класс, больше нигде запросов нет, только вызовы методов. К тому же, все названия полей перечисляются явно, потому при обновлении структуры БД места где новые поля не используются не сломаются, и не потребуют редактирования.
Переменные с большой буквы (с одним исключением) именуются с большой буквы, к тому же если посмотреть на определение переменной:
$L = Language::instance();
Дополнительных вопросов возникнуть не должно. В данном конкретном случае название класса слишком длинное, если вам так больше понравится — можно использовать функцию __(), которая является оберткой, и привычна многим.
По поводу даты — спасибо, вы нашли опечатку, исправлено.
Как раз всё лежит в вполне предсказуемых местах. Всё что касается модуля только в его директории, системные классы и функции в core относительно корня. Добавление и редактирование поста в разных файлах, по скольку это разные страницы. Вв фреймворке, вероятнее всего, это были бы два метода (action) одного контроллера + две (или одна) view, а здесь это два файла. Непосредственно манипуляции всё равно производятся в одном классе, остальное — графическая обертка над этим + права доступа. На счёт удаления не понял о чём именно речь, поиск по проекту «add_internal» не нашел.
Вы можете назвать хотя бы пять CMS с нормальной иерархией, по стандарту PSR-0 или PSR-1, с адекватным (по вашему мнению) подходом к запросам БД, одновременно с этим, чтобы устройство CMS не было слишком сложным, и для поддержки проекта не потребовалось бы много средств и времени?
Спрашиваю ради ознакомления, это не троллинг.
Спрашиваю ради ознакомления, это не троллинг.
Я мало связан с CMS'ками, но тот же Drupal 8 был переписан используя Symfony. И поддержка PSR-1 в нем есть точно, а вот насчет PSR-0 — то вроде у модулей, внутри самой системы есть, а насчет остальных частей — не знаю. Ну а вообще, я стараюсь убеждать заказчиков, что CMS для чего-то отличного от блога — это плохо, даже для статических страниц.
Сейчас сообщество PHP разделилось на два фронта:
1. CMS разработчики — сам PHP знают очень мало, умеют на WP поставить плагины и, как они сами говорят «обернуть в AJAX». Самая многочисленная группа;
2. PHP разработчики — это люди, которые пишут используя всю мощь текущих наработок PHP. Для них слова: Composer, PSR-4, Generator, Trait, ORM, и другие — это общеупотребимые слова.
И эти два фронта в последнее время все дальше и дальше расходятся, что дальше может привести к созданию полноценного форка PHP, в котором PHP разработчики добьются добавления тех же: нативных аннотаций, type hint'ов для скалярных типов, и т.д.
К чему я виду? К тому что обилие таких CMS'ок еще больше усугубляет такой раскол. Разработчики Drupal при представлении Drupal 8 кстати об этом всем говорили.
Сейчас сообщество PHP разделилось на два фронта:
1. CMS разработчики — сам PHP знают очень мало, умеют на WP поставить плагины и, как они сами говорят «обернуть в AJAX». Самая многочисленная группа;
2. PHP разработчики — это люди, которые пишут используя всю мощь текущих наработок PHP. Для них слова: Composer, PSR-4, Generator, Trait, ORM, и другие — это общеупотребимые слова.
И эти два фронта в последнее время все дальше и дальше расходятся, что дальше может привести к созданию полноценного форка PHP, в котором PHP разработчики добьются добавления тех же: нативных аннотаций, type hint'ов для скалярных типов, и т.д.
К чему я виду? К тому что обилие таких CMS'ок еще больше усугубляет такой раскол. Разработчики Drupal при представлении Drupal 8 кстати об этом всем говорили.
Если вы читали статью — то могли бы заметить, что от CMS тут больше названия чем чего-либо другого. Это CMF, ядро со всеми компонентами, которые нужны для разработки функциональности заказчика. Это предполагается как фундамент, который максимально прост, но при этом самодостаточен, работает и адекватно настроен из коробки, но позволяет переопределить практически всё что угодно при необходимости, даже системные классы, не редактируя при этом файлы ядра, и сохраняя возможность обновления.
Это как сконфигурированный, собранный из разных компонентов фреймворк который сразу готов к работе и открыт для модификаций.
Всё что нужно движку идет с ним в комплекте, тем не менее если движок увидит наличие composer.json — он включить его в дистрибутив, если его папка vendor будет обнаружена на установленной системе — автозагрузчик composer будет автоматически подключен, и все сторонние компоненты будут автоматически доступны ровно так же, как и компоненты ядра системы. Ядро вообще не против всего этого, просто оно само по себе в этом не нуждается, но при наличии прозрачно интегрируется и просто работает.
То есть тут используются новые штуки PHP, те же Trait, но при этом подход совсем другой, не предполагается что вы возьмете класс (или набор классов) для работы с пользователями, и замените его полностью на сторонний, либо начнете использовать в стороннем проекте. Тем не менее как показывает практика достаточно простой код легко переносится на другие платформы, и я не вижу здесь смысла писать слишком высокоабстрактный код, лишь бы предоставить мнимую переносимость и interoperability (не знаю как правильнее перевести), которая используется очень редко. Система вообще скорее для разработчика, которому нужна платформа с предоставлением нужных рабочих интерфейсов, которые не требуют километров yaml конфигов, формат которых нужно держать в памяти, а банально работают сразу. Разработчик занимается непосредственно бизнес-логикой, и я верю что это и должно быть подавляющим объемом написанного кода.
Это как сконфигурированный, собранный из разных компонентов фреймворк который сразу готов к работе и открыт для модификаций.
Всё что нужно движку идет с ним в комплекте, тем не менее если движок увидит наличие composer.json — он включить его в дистрибутив, если его папка vendor будет обнаружена на установленной системе — автозагрузчик composer будет автоматически подключен, и все сторонние компоненты будут автоматически доступны ровно так же, как и компоненты ядра системы. Ядро вообще не против всего этого, просто оно само по себе в этом не нуждается, но при наличии прозрачно интегрируется и просто работает.
То есть тут используются новые штуки PHP, те же Trait, но при этом подход совсем другой, не предполагается что вы возьмете класс (или набор классов) для работы с пользователями, и замените его полностью на сторонний, либо начнете использовать в стороннем проекте. Тем не менее как показывает практика достаточно простой код легко переносится на другие платформы, и я не вижу здесь смысла писать слишком высокоабстрактный код, лишь бы предоставить мнимую переносимость и interoperability (не знаю как правильнее перевести), которая используется очень редко. Система вообще скорее для разработчика, которому нужна платформа с предоставлением нужных рабочих интерфейсов, которые не требуют километров yaml конфигов, формат которых нужно держать в памяти, а банально работают сразу. Разработчик занимается непосредственно бизнес-логикой, и я верю что это и должно быть подавляющим объемом написанного кода.
Вы говорите, что мало связаны с CMS'ками, но беретесь судить что плохо/хорошо для них, оперируя понятиями, которые ближе для фреймворков и отдельных скриптов. Если вы убеждаете заказчиков, что CMS для чего-то отличного от блога — это плохо, значит вы относите себя ко второму типу разработчиков и не видите прослойки между первым и вторым типов в виде создателей CMS-велосипедов, которые пишут поделки, облегчающие и автоматизирующие типичные действия. Пишут сначала для себя, а затем, когда проект разрастается, уже и для других. В мире более 1000 CMS и каждый день появляются новые. Они в корне отличаются от скриптов и фреймворков. В первую очередь тем, что обычно не нужно лезть в код. И сайты можно создавать не зная PHP, соответственно и ориентация идет в первую очередь на пользователей не программистов. Есть системы модульные, позволяющие писать различные дополнения и для расширенной разработки на них достаточно знать, как эти дополнения разрабатывать. А есть и монолиты, которые, несмотря на старый ненормативный код, довольно шустро работают и позволяют сделать очень многое за очень малое время. Всё зависит от задачи.
Друпал же не относится к легким для освоения CMSкам, он скорее для программистов, особенно из-за многочисленных проблем с модулями и их устареванием/совместимостью/работоспособностью/безопасностью.
Друпал же не относится к легким для освоения CMSкам, он скорее для программистов, особенно из-за многочисленных проблем с модулями и их устареванием/совместимостью/работоспособностью/безопасностью.
1. На счет предложения использовать отдельные компоненты и конкретно (https://github.com/nazar-pc/CleverStyle-CMS/blob/master/core/classes/Page/Includes_processing.php) — при поверхностном взгляде:
2. В админке загрузил первый попавшийся файл в «загрузить и обносить систему» — словил белый экран (http://demo.cscms.org/admin/System/components/modules/update_system).
дальше смотреть не стал.
Вообще жаль, что тенденция такова, что каждый PHP разработчик пишет свою CMS, причем повторяя 90% функциональности, идей и ошибок. Направить бы усилия в одно русло. Это я говорю как человек, который тоже прикладывает руки к написанию CMS (не своей, но общественной).
- строка 77: сработает ли условие если в url путь указан в кавычках? ( url('some/image.jpg'))
- ф-я `is_relative_path_and_exists` требует доработки, т.к. путь может быть и таким "//yastatic.net/bootstrap/3.1.1/css/bootstrap.min.css"
2. В админке загрузил первый попавшийся файл в «загрузить и обносить систему» — словил белый экран (http://demo.cscms.org/admin/System/components/modules/update_system).
дальше смотреть не стал.
Вообще жаль, что тенденция такова, что каждый PHP разработчик пишет свою CMS, причем повторяя 90% функциональности, идей и ошибок. Направить бы усилия в одно русло. Это я говорю как человек, который тоже прикладывает руки к написанию CMS (не своей, но общественной).
1.
2. Это баг не движка, а HHVM, я его обнаружил уже после загрузки демки, баг в несовместимости реализации работы с phar файлами в PHP версии от Zend и HHVM, отрепортил разработчикам: https://github.com/facebook/hhvm/issues/4012, постараюсь заменить HHVM на PHP-FPM, чтобы демка была полнофункциональной.
Если ещё что-то заметите — буду рад узнать, если что можно писать в личку.
- Об кавычках, как одинарных, так и двойных беспокоится строка 79, решил таким образом упростить регулярку.
- в `is_relative_path_and_exists` последний компонент проверяет на то, что путь начинается со слэша, если так — то это абсолютный путь (относительно корня сайта, либо двойной для совсем внешних файлов — не важно), который мы игнорируем при минификации, то есть оставляем как есть, он при перемещении сжатого css в другую папку (с кэшем) не сломается
2. Это баг не движка, а HHVM, я его обнаружил уже после загрузки демки, баг в несовместимости реализации работы с phar файлами в PHP версии от Zend и HHVM, отрепортил разработчикам: https://github.com/facebook/hhvm/issues/4012, постараюсь заменить HHVM на PHP-FPM, чтобы демка была полнофункциональной.
Если ещё что-то заметите — буду рад узнать, если что можно писать в личку.
К стати, позиционирование в Cotonti, похоже, очень похоже на CleverStyle CMS. А вот код выглядит старо, либо мне просто так показалось.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура модуля CleverStyle CMS