Доброго времени суток. Разрабатываю фреймворк решил поделить первыми версиями task-framework.blogspot.com https://habr.com/ru/post/523828/ О фреймворке Task framework основан на MVC парадигме с удобством использования и минимум функционала для решения простых задач. В отличие от стандартных решений вместо контроллера тут используется задача (task) jsock-framework-tutorial.blogspot.com java-framework-jsocket.blogspot.com github.com/nnpa/jsock Установка фреймворка task 1. Скачайте архив с фреймворком 2. Распакуйте в папку task в директорию где у вас хранятся сайты. 3. Скачайте каркас для приложения 5. Распакуйте в папку site в в директорию где у вас хранятся сайты. 6. Создайте базу данных в mysql. 7. Скачайте таблицу users и экспортируйте в созданную базу данных. Должно получится такое дерево каталогов /webroot/task /webroot/site 8. Настройте веб сервер что бы корневая папка /webroot/site была привязана к определенному хосту при помощи веб сервера который вы используете. 9. Зайдите в папку config и откройте config.php и отредактируйте массив подключения к базе данных на ваши значения подключения и переменную host. MVC парадигма Task framework использует MVC парадигму для лучшего разделения логики шаблонов представлений, моделей и контроллера. Вместо контроллера в Task framework используются задачи Task — задачи расположены в папке tasks и предназначены для выполнения логики приложения. Модели хранятся в папке models и предназначены для работы с логикой базы данных. Представления хранятся в папке view и предназначены для работы с логикой представления. Task Task (или Controller) располагаются в папке tasks. Task создаются по переменной в url сайта request: Если переменная request = test то будет создан экземпляр класса Task который хранится в папке tasks в файле test.php и называется test. index.php?request=test Пример класса test.php: Код (Text): include_once('WebTask.php'); class Test extends WebTask{ public function run(){ //логика приложения } } Обязательно task должен быть унаследован от WebTask и в нем должен быть создан метод run() Models Models располагаются в папке models и отвечают за логику работы с базой данных. Модели привычнее всего создавать в tasks. Модель должна быть создана в папке models и быть унаследована от Model так же должно быть прописано поле $table_name. Пример класса models/users.php: Код (Text): class Users extends Model{ public $table_name = 'users'; } В классе Model заранее реализован набор методов для работы с базой данных. findBySql Код (Text): $users = new Users(); $users->findBySql("SELECT * FROM `users`"); foreach($users as $user) { echo $user['email'] . "<br>"; } findByPk Код (Text): $users = new Users(); $users->findByPk(3); echo $users->email; find Код (Text): $users = new Users(); $users->find("email <> ''"); foreach($users as $user) { echo $user['email'] . "<br>"; } update Код (Text): $users = new Users(); $users->findByPk(3); $users->email = "yandex@mail.ru"; $users->update(); save Код (Text): $users = new Users(); $users->email = "yandex@mail.ru"; $users->id = NULL; $users->save(); delete Код (Text): $users = new Users(); $users->delete("id = 6"); exec Код (Text): $users = new Users(); $users->exec("free sql string"); //mysqli_result DB Код (Text): App::$DB->exec("free sql string");//mysqli_result view Шаблоны представлений хранятся в папке /view/ отвечают за логику представлений. Представление вызывается в конце метода run класса task при помощи метода render. В представление передаются переменные которые будут использованы в логике представления. Пример site task: Код (Text): include_once('WebTask.php'); class Site extends WebTask{ public function run(){ $users = new Users(); $users->find("email <> ''"); $this->render('site',[ 'users' => $users, ]); } } В методе run модель с пользователями передается в шаблон view/site.php где происходит обработка результатов поиска и генерация html: Код (Text): <?php foreach($users as $user) { echo $user['email'] . "<br>"; } ?> Так же в папке view/layout расположен основной шаблон main.php который является главным шаблоном куда в переменную {content} подгружаются наши представления. Авторизация пользователя В фреймворке уже реализована регистрация и авторизация по ссылкам login и register. Метод приложения который позволяет проверять являет ли пользователь авторизованным App::isGuest() В завершении task-framework blog Фреймворк будет дальше разрабатывать и тестироваться на разрабатываемых на нем приложениях. Cпасибо.
Копипаст рулит! И модеров не учили норм. оформлять вставки кода? Как я понял, задача отличается от контроллера только тем, что у нее название короче Или есть какие-то существенные отличия?
Поправил вставил Код (Text): Да задача короче контроллера и там нет реализации прав пользователя и в модели нет проверки правильности полей В целом фреймворк легче и проще чем yii и laravel
Шаблонизатор какой? Есть ли возможность гибкой настройки роутов? И разграничения методов get/post/put/delete ?
Походу там захардкодено во фронте дерганье задачи по GET-параметру: --- Добавлено --- Нужно скачать посмотреть --- Добавлено --- PHP: <?php include_once(App::$document_root . DIRECTORY_SEPARATOR . "config". DIRECTORY_SEPARATOR ."config.php");?> <?php App::run($config); ?> Вывод пустой строки перед App::run, серьезно?
PHP: include_once($task_path); $task = new $request(); Инклудим практически любой php-файл. Нет никакой защиты от request=../file и т.п. Если файл загружен взломщиком, то в нем можно спокойно переопределить $request и все будет шито-крыто.
Шаблонизатора никакого - как говорят php и есть лучший шаблонизатор Насчет настройки роутов нужно подумать Разграничений тоже нет этим роутинг ближе к yii в laravel есть такая настройка --- Добавлено --- Попробую заглушку поставить и поинклудить
На какую нишу направлен фреймворк? Каковы плюсы? Есть ли примеры его практического использования? И это.. инклуды прям так писать - позапрошлый век. Прочтите про автозагрузки классов
Инклудить контроллер явно вполне норм. (если фронту известен способ образования имени подключаемого файла). А вот всякие модельки и т.п., да, можно через автозагрузку.
С одним экшеном – это, наверное, для REST-приложений. Правда, там обычно бывает еще деление по типам HTTP-запросов, о чем ты выше спрашивал, но в простейшем случае это можно разруливать внутри единственного обработчика. Также можно на уровне Web-сервера распределить запросы разных типов по разным задачам, хотя это и отстой.
Если для сервисов и апи, то точно надо возможность разделения методов и гибкий роутинг, с масками переменных и тем же разделением методов, + не помешали бы методы ответов а json с статусами ответов (200, 404) итд