PHPixie против Laravel

Кто генерит XML темплейтингом? гораздо проще ведь использовать 300 библиотек для работы с ним. Зачем вам в XML лейауты и блоки??

PHPixie против Laravel

https://github.com/PHPixie/Framework/blob/master/src/PHPixie/Framework/Components.php

уже есть, не везде, но в самых востребованых местах точно

PHPixie против Laravel

Ну во первых как я уже писал раза 3 можно просто писать <?= и <?php. Но на самом деле распространять PSR на файлы темплейта как то уж очень притянутотак как они писаны для кода а не для шаблонов. Это то же самое что с endif, в коде класса он совсем ни к чему и руки за такое ломать, но для шаблона самое оно.

PHPixie против Laravel

register_globals и magic_quotes выпилили суто по причинам безопасности а не потому что они меняют язык. При чем здесь короткий тег?

В любом случае, вы всегда можете просто использовать длинный, в чем проблема собственно? Кстати тег "<?=$bla?>" теперь доступен всегда вне зависимости от ini настроек.

Так что даже если использовать доинный тег то тол ко в ифах и форичах придется

PHPixie против Laravel

Вот так прочитайте это предложение еще раз. Он discouraged потому что у кого-то он модет быть выключен. Тоесть если вы делаете плагин для вордпреса который должен на каждом хостинге заработать то конечно же лучше полный тег писать. Но если это ваш сервер то вы сами его настраиваете.

Это то же что сказать что все фичи PHP7 discouraged так как не у всех он есть.

PHPixie против Laravel

С чего это они discouraged? Вы сами придумываете проблемы.

А насчет скорости работы, бенчмарки посмотрите =) И кстати и ларавел и симфони используют output buffering для рендеринга как и пикси. Так что выдумки все это

PHPixie против Laravel

https://gitter.im/PHPixie/Hotline

PHPixie против Laravel

<?php $this->layout('layout.desktop'); ?>

<? $this->startBlock('nav'); ?>
    <? if(isset($nav)): ?>
        <? foreach($nav as $link => $title): ?>
             <a href="<?=$link ?>"><?=$_($title) ?></a>
        <? endforeach; ?>
   <? else: ?>
        <span>Главная</span>
   <? endif; ?>
<? $this->endBlock(); ?>

<h1>Hell or World?</h1>

PHPixie против Laravel

Так имхо тогда в пиксе лучше нет? Все то же, только без дополнительного языка и компиляции, да еще и дебажить легче

PHPixie против Laravel

$_ намного короче :)

PHPixie против Laravel

Почему? Пикся давно уже не микрофреймворк, в ней куча всего из коробки

PHPixie против Laravel

Ну уже заставить себя написать в стиле

<?=$_($var)?>

вместо просто

<?=$var?>

не так уж трудно. На самом деле если не доверять разработчикам что они вывод нормально сделают, то к базе запросы их пускать писать уж тоже нельзя. Еще сделают Delete запрос без условий и продакшн потрут

PHPixie против Laravel

Намного лаконичнее получилось, мне бы так писать =)

PHPixie против Laravel

А думать то как? На стену смотреть?

PHPixie против Laravel

Потому-что на следующий день сутра ты поймешь что надо было сделать совсем по другому. Я ОРМ этот раз наверно 20 переписывал. С первого раза придумать нормальную архитектуру и протестировать можно разве-что CRUD всякий. А когда пишешь темплейтинг тебе свежие идеи лезут одна за другой. И тут важно каждую попробовать и отобрать лучшую, тут и помогают тесты высокого уровня, так как они всегда остаются. А вот если я сегодня начал делать подгрузку связей джойном, и напишу тесты для правильных джойн запросов, а завтра решу что лучше было сделать без джойнов совсем а по айдишкам, то тесты запросов уже тоже можно выбросить, так как этого класса даже не останется. А вот если тест выского уровня и просто проверяет все ли подгрузилось, то ему все равно как я имплементировал.

И вот когда уже я точно знаю какой подход выбрать я напишу юнит тесты.

PHPixie против Laravel

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

Как раз такими маленькими тестами классов и получается вытянуть покрытие к 100%. А вот эти хай-левел тесты которые проходят через всю систему я держу только для рефакторинга и кавередж ними не считаю

PHPixie против Laravel

Во владении русским языком Вы уступаете даже Вите АК. Вы могли, хотя бы, авто-корректором каким-то пройтись?

Уже по ходу прошелся, щас еще попробую =)

Тесты пишутся перед написанием кода, документация тут не причем.

Не все. Я например сначала делаю функциональные тесты высокого уровня, которые просто запускают все и проверяют результат. Это позволяет мне дальше думать над архитектурой. Когда архитектура уже готова можно углубляться в юнит тесты. Глупо писать юнит тест для класса, который я завтра удалю совсем и разобью на три. Конечно тесты в стиле сохранится ли что-то в БД вообще хороши всегда. Если взглянете на тесты к ОРМ, там отдельно есть функциональные которые пишут и читают с БД и отдельно юнит, которые тестируют сами классы.

Не совсем уместное сравнение — Вы можете вставлять чистый PHP (не ПХП) код в шаблоны Blade.

Это не считается хорошей практикой. И для поддержки блоков и наследования придется использовать блейд все равно

Это семантическая бессмыслица. Laravel позволяет вместо имени контроллера передать closure, и это не имеет никакого отношения ни к байндингу, ни к монолитной архитектуре (которой у него нет).

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

Валидировали, валидировали… и вывалидировали! Сравниваем валидаторы данных в PHP

А еще не забываем о PHPixie Validate, который в отличии от других библиотек работающих только с одномерными массивами умеет валидировать вложенные структуры типа:

$data = array(
    'name' => 'Pixie',
    'home' => array(
        'location' => 'forest',
        'name'     => 'Oak'
    ),
    'spells' => array(
        'charm' => array(
            'name' => 'Charm Person',
            'type' => 'illusion'
        ),
        'blast' => array(
            'name' => 'Fire Blast',
            'type' => 'evocation'
        ),
        // ....
    )
);

Что фактически необходимо при работе со всякими ангулярами и MongoDB

PHPixie Social — простая интеграция с соцсетями

В-третьих, в том же HWIOauth есть почти все провайдеры которые требуются, а добавлять их на самом деле не так просто как кажется.

я добавил 4 к пиксе вместе с абстрактным Oauth адаптером за 2 дня где-то.

А насчет интеграции с другими компонентами это совсем не так, на самом деле в самом фреймворке даже нет интеграции с Social, все далаеться через адаптеры типа: https://github.com/phpixie/auth-social и ничего не мешает сделать такой-же адаптер для HybridAuth

Кстати вот например OmniPay я переписывать не собираюсь, для него будет просто адаптер =)

PHPixie Social — простая интеграция с соцсетями

Для каждого сервиса все равно пришлось бы писать классы токена для сериализации. На самом деле велосипдность минимальная, так как в oauth нет ничего сложного совсем. Но зато получаете библиотеку построену с psr4 с более красивым кодом. А добавить сервисов плевое дело, только скажите какие вам надо. А писать провайдер для например Yahoo, который никому не надо просто для количества, смысла нет.