В совокупности с неинтуитивным роутингом в YII
В Yii3 обещается более удобный роутинг, чем в предыдущих версиях, похожий на роутинг Laravel.
В совокупности с неинтуитивным роутингом в YII
В Yii3 обещается более удобный роутинг, чем в предыдущих версиях, похожий на роутинг Laravel.
PS Возможно, что будет нужна функция Hleb\Static\System::getTaskPermissions() для того, чтобы определить заранее, может ли конкретная задача выполняться в нужном режиме.
UPD Если изменить маршрут на:
// Файл /routes/main.php
Route::any('/{controller}/{method}')
->module('common', 'Modules\Common\Controllers\<controller>Controller@action<method>');
то будет более полная подстройка под Yii2, так как теперь только методы контроллера начинающиеся с "action" будут участвовать в подборе совпадений. Например, адрес /site/index будет указывать в контроллер модуля SiteController и его метод actionIndex(). При этом в rules() останется по прежнему ключ 'index' в данном случае.
Часть подобных статей вынес в раздел "Вопросы", с недавнего времени он также пополняется категорией FAQ, так что велком.
Нужно настроить права на папку storage по этой инструкции https://hleb2framework.ru/ru/2/0/settings
Если после установки демонстрационная страница открывается без проблем, то на начальном этапе он установлен и работает. Можно ещё проверить подключение к базе данных, сделав произвольный запрос на выборку.
Если ваше приложение будет работать с базой данных, необходимо установить расширение PHP PDO и соответствующий драйвер (например, pdo_mysql для MySQL).
В остальном фреймворк по умолчанию работает с базовым набором расширений PHP. Дополнительно устанавливать ничего не нужно.
Конфигурационные файлы, в том числе для настройки баз данных, хранятся в папке config. Подробнее про конфигурацию https://hleb2framework.ru/ru/2/0/configuration
Для подключения к базе данных MySQL найдите файл config/database.php (или config/database-local.php, если он есть) и измените блок, который по умолчанию имеет название 'mysql.name', также убедитесь, что в 'base.db.type' выставлено это название.
// База данных по умолчанию:
'base.db.type' => get_env('DB_TYPE','mysql.name'),
// Список баз данных:
'db.settings.list' => [
'mysql.name' => [
'mysql:host=localhost',
'port=3306',
'dbname=%dbname%', // Название базы данных
'charset=utf8',
'user' => '%username%', // Имя пользователя
'pass' => '%password%', // Пароль
],
]
Об уровне подачи информации у этой организации можно судить по статье на Хабре . За эту статью упомянутая там компания подала в суд и пришлось срочно вносить в статью изменения. Неужели хваленые юристы профсоюза ничего в статье не обнаружили перед выкладкой? Делайте выводы.
Эти две версии отличаются очень сильно, но просматривается приемственность.
В общем - HLEB1 поддерживает версии php 7.2 - 8.2 и на текущий момент не развивается, только поддержка безопасности.
Все силы направлены на HLEB2, этот фреймворк современнее, в нем учтены нюансы разработки первого фреймворка и он имеет более расширенные возможности.
Вот связанные посты на эту тему:
Переход на HLEB2 c первой версии фреймворка
Отчет по подготовке версии HLEB 2.0
Вместо отчёта по фреймворку HLEB 2
Небольшое уточнение к Dependency inversion - имеется ввиду, что все используемые зависимости класса должны исходить из его интерфейса и быть там как бы зафиксированы.
Встретил интересное мнение, что принцип разделения интерфейсов противоречит принципу единой ответственности. Если класс должен делать что-то одно, то больше одного интерфейса ему не потребуется. Такие вопросы как раз и возникают из-за буквального понимания единой ответственности. Если это модуль, как набор классов, объединенных одной целью, как описано выше, то можно представить ситуацию, когда он используется в рамках только одного из этих составляющих классов. В теории имеется ввиду именно логическое разделение интерфейсов, без пересечения друг с другом, таким образом можно создать изначально подготовленный для всех случаев использования класс.
Недавно читал перепалку программистов, что преимущество Symfony перед другими PHP-фреймворками как раз в том, что Symfony не позволяет писать "плохой" код. Как раз описанный выше проект на этом фреймворке, что показывает, что фреймворк не может повлиять на качество кода разработчика, и дело совсем не в инструментах, а какие руки эти инструменты держат.
Добавил в оформление картинки сгенерированные нейросетью Midjourney
Что касается "переписать нельзя рефакторить", запятую расположите по усмотрению, то этот выбор зависит от того, на каком этапе находится проект, монолит ли это или микросервисы, есть ли достаточно ресурсов и есть ли конкретный план развития проекта. Выше указано, что переписывание всего кода малоприемлимо для бизнеса и почти недостижимо, если производится усилиями той-же команды, что и создавала проект.
Полностью переписывать часто рекомендуют после пилотной версии проекта, когда еще не встали на рельсы разработки, но результаты показывают , что у проекта может быть будущее. Но так как здесь нет чётких границ, эта фаза плавно перетекает в развивающийся стартап и быстро прогрессирующее количество кода.
Добрый день! Вот в этом случае
SettingModel::editPassword(['id' => $user_id, 'password' => $newpass]);
если подразумевается, что есть необходимость менять пароль произвольному пользователю, а не только текущему, то этот метод имеет место быть. Для упрощения в коде вы можете добавить метод
public static function editPassword(int $userId, string $newpass) {
// ...
}
public static function editCurrentUserPassword(string $newpass) {
return self::editPassword(UserData::getId(), $newpass);
}
и пользоваться и тем и тем. Создавать через конструктор не во всех случаях полезно, так как не во всяком обращении к модели пользователей вам нужен именно текущий пользователь, впридачу методы здесь статичные в модели и обращение идёт к классу, а не объекту.
Ещё одной причиной, ведущей к быстрому нарастанию технического долга, часто бывает использование стороннего кода, фреймворков, библиотек, над которыми нет вашего контроля. Эти библиотеки не могли и не могут предусмотреть всех функций, которые от них потребуются для развития конкретного продукта и задач, стоящих перед его маркетологами. Стараясь обогнать конкурентов, которые, возможно, также пошли на сделку с совестью, сделав поверх этой же библиотеки изощрённый костыль, могут появиться задачи, для которых этот сторонний код не предназначен.
Появляется проблемный выбор: или из-за небольшой задачки переписывать всё под другую библиотеку, тоже не универсальную; или менять код самой библиотеки, предварительно её изучив, навсегда отказавшись от автообновлений и развития из её оригинальной версии; или начать писать собственную версию, без поддержки сообщества и надеясь на компетентность собственных разработчиков.
Двигаясь по этим направлениям, можно избежать технического долга, однако после озвучивания количества ресурсов, которые нужны, скорее всего вас попросят пойти на копромисс, добавив в систему запутанность с помощью легкого решения.
В дальнейшем, разработчики этой библиотеки, совершенно не зная, что вы используете её каким-то иным образом, добавят обновление, в котором у вас может быть поломка. Все равно будет затем потрачено некоторое кол-во времени на отслеживание всех зависимостей с исправлением, и мысль о том, что после этого не случиться подобное ещё раз и ещё раз, в ближайшей перспективе может и не появиться, в дальней перспективе это нарастающий технический долг.
При удалении папки database в файле composer.json нужно удалить маппинг на эту папку:
"autoload": {
"classmap": [
"app/",
"database/", <- эту строку удалить
"vendor/phphleb"
],
...
Это нужно для того, чтобы не было проблем с автозагрузчиком composer и перегенерацией классов.
Инструкция по настройке работы фреймворка для Open Server Panel
@YuraN, озадачившись вопросом переустановил Open Server 5.4.3 (на Windows 10), выбрал PHP 8.1, MySQL 8.0, направил домен в папку public проекта (тот, что под этим постом по ссылке на архив),
создал базу test и внёс настройки:
define ("HLEB_TYPE_DB", "mysql.example");
define("HLEB_PARAMETERS_FOR_DB", [
"mysql.example" => [
"mysql:host=localhost",
"port=3306",
"dbname=test",
"charset=utf8",
"user" => "root",
"pass" => "",
]
]);
Выполнил команду php console hlogin/create-login-table-task
в корне проекта, чтобы сгенерировать нового администратора. Под ним захожу свободно, лайки ставятся, пользователи добавляются. Так что воспроизвести проблему не удалось.