Дивовижний фреймворк phalcon

    Нещодавно в нашій компанії було вирішено спробувати фреймворк phalcon c метою в перспективі дещо отрефакторіть і в новому коді використовувати саме його. Причини банальні — швидкість роботи, симпатичний orm.
 
Але от у процесі тестування фреймворка у мене в голові все частіше і частіше став спливати термін «Принцип найменшого подиву». І саме тому, що я все більше і більше дивувався.
 
 
 
ORM і порожні рядки
Візьмемо стандартну ситуацію. Табличка
Users (id int, name varchar, comment varchar not null default '')
. Створимо модель User для роботи з цією табличкою і спробуємо створити нового користувача:
 
 
$user = new User();
$user->id = 1;
$user->name = 'Robot';
$user->save();

І… користувач не створюється. Якщо подивитися помилки для моделі побачимо таку: «comment is required» . WTF скажете ви і будете праві :) Баг? скажете ви і будете не праві.
 
Дивимося Issue 440 від 22 лютого минулого року і бачимо, що це фіча.
 
Причини цієї фічі — моделі часто створюються і зберігаються після відправки користувачем даних з форми, багато функцій, які програміст _может_ використовувати для валідації (strip_tags, filter_var) при подачі їм NULL на виході видають порожню рядок. Тому програміст гіпотетично може отримати випадок, коли поле comment не буде відправлено через форму
($_POST['comment']==null)
, але програміст використовував
$user->comment = strip_tags($_POST['comment']);
і отримав замість null значення'' в поле comment.
 
Дивно? По мені так дуже.
 
Рішення, до речі, наводяться . Але через цю старанність доводиться перевизначати стандартну валідацію.
 
Ну і ще один приклад з тієї ж області:
 
 
$user = User::findFirst("name='robot'");
$user->name='robot2';
$user->save();//!!!!!!WTF?

 
 
Папки для views
Шаблони в проекті можуть лежати в декількох місцях, наприклад окремо шаблони для кожного модуля, окремо базовий шаблон проекту.
 
Що робити, якщо хочемо в шаблоні модуля зробити
{% extends base.twig %}
? Правильно, додати в налаштуваннях view додаткову папку для пошуку базового шаблону. Але
View::setViewsDir
приймає як параметр тільки одну директорію!
 
New feature request на це був відправлений 15 грудня минулого року
 
У якості часткового рішення можна вказати як шляху до шаблонів папку з модулями і потім вказувати в контроллерах повний шлях до шаблону від папки з модулями (
$this->view->pick("clients/views/index");
). Або відключити автоматичний виклик рендеринга при налаштуванні додатки (
$application->useImplicitView(false);
), в якості View використовувати
Phalcon\Mvc\View\Simple
і рендерить шаблони вручну
print $this->view->render('clients/views/client_view', []);

 
Ось, до речі, ще одне здивування — стандартний View не вміє рендерить шаблони по шляху, тільки по імені контролера / дії (
$this->view->render('controller', 'view', []);
), тому в даному випадку потрібно використовувати Simple.
 
 
Дивний синтаксис insert / update DBAL
Я настільки звик до синтаксису insert / update Doctrine DBAL, що й подумати не міг, що можна зробити якось по іншому. Виявляється можна.
 
Синтаксис phalcon DBAL і Doctrine DBAL:
 
$success = $connection->insert(
        "robots",
        array("Astro Boy", 1952),
        array("name", "year")
    );

і
 
$success = $connection->insert(
        "robots",
        array(
            'name' => "Astro Boy",
            "year" => 1952
        )
    );

 
 
$success = $connection->update(
        "robots",
        array("name"),
        array("New Astro Boy"),
        "id = 101"
    );

і
 
$success = $connection->update(
        "robots",
        array("name" => "New Astro Boy"),
        array("id" => "101")
    );

  
По мені, так однозначно синтаксис Doctrine DBAL зручніше за рахунок уніфікації.
 
Я відправив pull request з концептом в phalcon incubator. Може бути додадуть небудь :)
 
В цілому, незважаючи на деякі незручності, від ідеї використовувати phalcon не відмовляємося, продовжуємо тестувати.
    
Джерело: Хабрахабр
  • avatar
  • 0

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.